On Fri, Aug 19, 2016 at 2:33 AM, <martin.stre...@gmail.com> wrote: >> It appears as though the signal handler is somehow not running on the >> alternate signal stack. I don't know why that would be, though. I >> have no other explanation. You'll have to debug it. >> > I can see by the stack pointers, that the alt stack is used on both, Linux > and Darwin. But I'm not familiar enough with the internals to debug why it > calls morestack/newstack.
The call to `morestack` is happening because the function `sighandler` thinks that the value of the stack pointer register is too close to the end of the current stack segment. In this case, the error message shows that the stack pointer is not in the current stack segment at all. The stack pointer at that point should be the alternate signal stack. The function `sigtrampgo` should have switched to the `g.m.gsignal` goroutine, whose stack should have been set up to be the alternate signal stack. So `sighandler` should never call into `morestack`. Something has gone wrong but I don't know what. >> What you are doing seems rather dubious but I can't think of any >> reason why it shouldn't work. > > Maybe you can shortly explain, why you think its dubious. I am calling a > shared C lib from Go, that spawns its own threads, and also calls back into > Go. According to the signal package documentation, registering a C signal > handler seems to be the only way to handle crashes in foreign threads. As I > want all non-Go threads to be dumped as well in case of a signal raised in > Go, I register the C handlers after the Go handlers. And instead of raising > the signal again, I call the Go handler directly to keep the original > mcontext. Do you think there's a better way to do it? I'm not sure which part of the os/signal docs you are thinking of. Crashes in Go code will work regardless of whether they are running on threads started by C or not. So I assume you are talking about crashes in C. How do you want to handle those crashes? Do you just want to try to dump the stack? How do you want to handle other C threads when one C thread crashes? I do agree that your code should work in principle, and I'm not sure why it doesn't. If all you wan to do is handle SIGSEGV when it occurs in a C thread, it may work to call signal.Notify(c, syscall.SIGSEGV). The channel will receive a signal wen a SIGSEGV occurs in C code. At that point it's not safe to continue, but it is safe to take whatever action you like to dump C threads. I'm not sure this will work, because it depends on what happens when the SIGSEGV signal handler returns to the C code that triggered the SIGSEGV. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
