x/mobile: avoid to catch sigabort signal

[Danilo bestbug]

Hello gophers,

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!

Thanks to everyone who will help me.

[Ian Lance Taylor]

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

[Danilo bestbug]

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?

[TheDiveO]

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.      

[TheDiveO]

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:

[Danilo bestbug]

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".

[Robert Engels]

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:



--
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.

[Danilo bestbug]

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.

[Kurtis Rader]

On Sun, Sep 10, 2023 at 10:41 PM Danilo bestbug <bestbug.c...@gmail.com> wrote:

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.

When you say "instead of be a complete executable" that suggests to me that a plugin is being used. I realize that English is not your native language but precision is important for this type of issue. Even if a plugin is not being used everything you have written suggests the problem is with your FFI code. In particular, issue https://github.com/golang/go/issues/61632 implies that a FFI function named `CMAC_resume` is calling Go code that detects its stack has been corrupted. That causes the Go runtime to raise SIGABRT to crash the program. So what does `CMAC_resume` do? Also, in this type of situation if you can't arrange for a core dump to be generated it is going to be very difficult to do a root cause analysis. Especially if you can't instrument the Cgo code that is causing the problem with debugging logging statements.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[TheDiveO]

CMAC_resume might be something from here, IIRC Darwin's OpenBSD anchestry: https://man.openbsd.org/CMAC_Init.3

[Danilo bestbug]

Ehy Kurtis, Ehy TheDiveO thanks for the answer.

Yes English is not my native language and I try to be precise as best as I can with my capabilities, thanks a lot for the patience and the effort on your side to understand what I'm sayings. Now that I read your answer is a little bit clearer how to read this stack regarding on what is happening. Thanks a lot! I wasn't sure about the CMAC_resume since the stack report CMAC_resume + 501884 which mean the offset from the CMAC_resume symbol is 501884, do you still think even with this offset is somehow trustable?

Thanks a lot