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.
