This most likely means your other code is corrupting the go runtime/heap/stack.
I would run other tests on this code exclusively (asan, etc). > On Sep 10, 2023, at 12:54 PM, Danilo bestbug <bestbug.corporat...@gmail.com> > wrote: > > > Hey TheDiveO, thanks for answering. > My focus is not to hide the signal but I would like to understand if this > behavior is wanted and in that case what we can do to avoid to have crash > report where the crashed thread does not run any of our "code". > > Il giorno domenica 10 settembre 2023 alle 18:12:37 UTC+2 TheDiveO ha scritto: >> Maybe this SO Q with A might also help with further details: >> https://stackoverflow.com/questions/47869988/how-does-cgo-handle-signals >> >>> On Friday, September 8, 2023 at 11:38:38 PM UTC+2 Danilo bestbug wrote: >>> Ehy Ian, thanks for the response. Apology if I was not clear, I try to >>> explain in a different way but it's hard for me too since I'm not 100% >>> confident about what it's happening here exactly, I'm tring to follow the >>> trace but any feedback is more than welcome. >>> The problem I'm facing is the following: I've a small utility written in GO >>> and integrated in an app iOS as SDK. At the moment if I've undestood >>> correctly from the thread I've linked the GO runtime are cacthing a >>> sigabort signal that are not from the GO stack but it's generated from >>> another thread with the result that it's look like the GO runtime is >>> crashing from the apple report. >>> >>> If this behavior of the GO runtime is legittime when GO is an executable in >>> my context is a problem since the developer follow the GO stack instead of >>> the other thread stack. >>> >>> Now what I'm try to understand if this behavior can be somehow change, and >>> if so how should I do? >>> Il giorno venerdì 8 settembre 2023 alle 22:34:07 UTC+2 Ian Lance Taylor ha >>> scritto: >>>> On Thu, Sep 7, 2023 at 11:41 PM Danilo bestbug >>>> <bestbug.c...@gmail.com> wrote: >>>> > >>>> > Some weeks ago I've opened a possible bug on github and the only >>>> > response I received is a reference to >>>> > "This looks like the program (the Go runtime, or not) intentionally >>>> > crashing when it is already in a bad condition, like receiving an >>>> > unhandled signal on a non-Go thread." >>>> > >>>> > I would like to stop the GO system to do this kind of behaviour >>>> > (intercepting unhandled signal) otherwise the team who work on the crash >>>> > keep searching the problem on the GO thread crashed instead of >>>> > elsewhere. This for us is a big problem and I love if someone can help >>>> > me to address this matter! >>>> >>>> I'm sorry, I don't really understand what you are asking. What I can >>>> tell you is that signal handling in Go programs is managed via the >>>> os/signal package. See https://pkg.go.dev/os/signal. >>>> >>>> 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/88739304-c34e-4a56-b7b4-85d763f71947n%40googlegroups.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/01BB404E-7755-4F3B-9041-A48EC3D86C1E%40ix.netcom.com.
