You seem to be barking up the wrong tree, at least for the moment. Maybe your team may want to learn more about cgo and by sheer coincidence there's a blog post https://shane.ai/posts/cgo-performance-in-go1.21/ that might serve as a starting point, with one or two pointers to go further. I also don't understand why you are so keen on the SIGABRT catch, when there is probably a much deeper problem in your code or the libs you use, s others already told you. Trying to hide the signal under the carpet isn't the best strategy to my limited understanding, as your app is already in such a bad state that the runtime has to fail. 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/4305ee4c-664a-43ff-b1d8-8e0439f74b91n%40googlegroups.com.
