Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
syscall: errors cannot be nested in Plan 9 #13770
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.
Yes, absolutely Plan 9 only. Feel free to flag it as such. I have been in touch with David, but neglected to warn him that I now have a github account so I could create an issue for this. I was also looking for some confirmation that my idea was not just the ravings of an uninformed contributor, nor totally impractical to implement :-) Regards. Lucio.