Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

syscall: errors cannot be nested in Plan 9 #13770

lootch opened this issue Dec 29, 2015 · 3 comments

syscall: errors cannot be nested in Plan 9 #13770

lootch opened this issue Dec 29, 2015 · 3 comments


Copy link

lootch commented Dec 29, 2015

To be more precise: as happens in "go doc", if two consecutive syscalls produce error messages, the second instance overwrites the string space used by the first and the result can be extremely confusing.

This is the result of some corrective action applied to resolve issue #4994, where a memory allocation following a syscall entry caused a failure,

Fixing this correctly is not trivial, so I was thinking of increasing the allocation to the single buffer reserved for Plan 9 syscall errors and instead of returning a pointer to its start, I would use a pointer that followed the most recently returned error message, wrapping around when the end of buffer was reached.

This is a hack, but if we allow for a handful of moderately sized error messages, we are unlikely to exceed the available space. If we do, we are no worse off, technically, than we are now, although debugging this situation would be somewhat more complicated.

If no one has a better idea, I propose to continue on this path, but I need some help. I can't figure out in the fourteen lines of runtime·errstr (runtime/sys_plan9_386.s, at the end of the file) how to adjust m_errstr. I'm sure it is not overly complicated, if you understand the assembler properly.

Also, there is the complication that we need to increment the buffer pointer ahead of fetching the error message because otherwise the message may be split between the end of the buffer and the beginning and we don't know until the message is returned how long it will be. That is serious, but not insurmountable.

Copy link

This sounds like it's only a Plan 9 issue? /cc @0intro

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Dec 29, 2015
@ianlancetaylor ianlancetaylor changed the title Syscall errors cannot be nested in Plan 9 syscall: errors cannot be nested in Plan 9 Dec 29, 2015
Copy link

lootch commented Dec 29, 2015 via email

Copy link

Change mentions this issue: syscall: eliminate aliasing of syscall error strings in Plan 9

@golang golang locked and limited conversation to collaborators May 8, 2019
@rsc rsc unassigned 0intro Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

5 participants