Hey Robert, The problem is not reproducible in our test env but it occours on final user. To make thing thougher is not even an application we develop directly but is from one of our reseller, so we don't have direct access to the rest of the codebase. Again I want to stress the main point of my request of help: if this behavior is caused by some corner case to have a GO runtime as third party dependencies instead of be a complete executable I would like to understand if we can do something better to avoid to have this stacktrace that are meaningless to us. Otherwise if this is a correct behavior from GO runtime, I think we still have a problem because usually the GO stacktrace are pretty clear about what is happening (and hence what to do to fix it) but not in this case.
Il giorno domenica 10 settembre 2023 alle 22:56:06 UTC+2 Robert Engels ha scritto: > 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.c...@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...@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 > > <https://groups.google.com/d/msgid/golang-nuts/88739304-c34e-4a56-b7b4-85d763f71947n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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/2b3199c4-ec4b-4b6f-8e54-43a478ebf206n%40googlegroups.com.
