Does this reproduce with older versions of Go as well, or is this new?

Judging by your analysis, this is true for older Go versions as well, hence why I put it in the backlog. If it's new, we probably need to deal with it this release.

Backlog is fine, I don't think this has ever worked. I'm not expecting this to get fixed for this release but trying to understand if this should work as is. To me it seems like they are doing some things that might not work with Go. And if that is the case is there another way this could be written to make it work, or at least not SEGV for platforms where this would be a problem.

Here is a summary as I understand their code where this started failing:

There is some C++ code to dump out all the stacks for a process.
A C++ signal handler for SIGRTMIN is created which calls libc's backtrace function.
A helper function reads /proc/self/task to create a list of all the threads in the process. Then it walks through the list and sends SIGRTMIN to each using rt_tgsigqueueinfo.
If there is a Go thread which receives the signal then the C++ signal handler is called and gets a SEGV in libc's backtrace.

A few things that seem suspicious (although this "works" on x86) and I don't know if they directly contribute to the problem:

• I don't think backtrace is async-safe so shouldn't be called from a signal handler
• The man pages for rt_tgsigqueueinfo say this is not intended to be used in user code. There is no libc wrapper for it.

If I write a program to call backtrace using cgo, this does not SEGV. The Go code will call asmcgocall before calling the C code and that will clear out the location for the backchain that backtrace expects. Since it is nil, backrace will stop at that point. In the scenario where Go code is running and is interrupted so the C++ signal handler gets control, there is nothing like asmcgocall in between to indicate that backtrace should stop.

I'm trying to create a smaller, simpler reproducer for this.

A simple reproducer of the backtrace crash for ppc64le can be done with some minor changes to the example in #46286 by replacing the obvious segfaulting code with a call to backtrace, and replacing the deadlock with a sufficiently long sleep.

A simple reproducer of the backtrace crash for ppc64le can be done with some minor changes to the example in #46286 by replacing the obvious segfaulting code with a call to backtrace, and replacing the deadlock with a sufficiently long sleep.

I meant a reproducer that has multiple Go and non-Go threads where a signal is sent to all to generate backtrace-type information like in the original issue.

The backtrace function is not officially async-signal-safe, but in practice it is. To make it work across Go code I guess that we would have to change the Go ABI to use the standard stack frame layout. That seems like it might be a good idea in general, much as we use frame pointers on x86. But I don't know how hard it would be.

I agree that using cgosymbolizer ought to work.

To make it work across Go code I guess that we would have to change the Go ABI to use the standard stack frame layout. That seems like it might be a good idea in general, much as we use frame pointers on x86. But I don't know how hard it would be.

If we could do this, that would be great. There are other tools the expect the PPC64 ABI so don't work correctly. I was always under the impression this was not an option due to compatibility issues. Something to investigate for the next release due to the work and risk.

I agree that using cgosymbolizer ought to work.

Based on my understanding, it would be better to have a Go signal handler to dump out the stacks for threads running Go and use cgosymbolizer from that signal handler. Does that seem like the right approach?

Based on my understanding, it would be better to have a Go signal handler to dump out the stacks for threads running Go and use cgosymbolizer from that signal handler. Does that seem like the right approach?

I think that should work, yes.