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.