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

Closed
lootch opened this issue Dec 29, 2015 · 3 comments
Closed

syscall: errors cannot be nested in Plan 9 #13770

lootch opened this issue Dec 29, 2015 · 3 comments
Assignees
Milestone

Comments

@lootch
Copy link

@lootch 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.

@bradfitz bradfitz added the OS-Plan9 label Dec 29, 2015
@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Dec 29, 2015

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
@lootch
Copy link
Author

@lootch lootch commented Dec 29, 2015

@gopherbot
Copy link

@gopherbot gopherbot commented May 3, 2018

Change https://golang.org/cl/111195 mentions this issue: syscall: eliminate aliasing of syscall error strings in Plan 9

@gopherbot gopherbot closed this in 1b49487 May 8, 2018
@golang golang locked and limited conversation to collaborators May 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.