Re: [go-nuts] x/mobile: avoid to catch sigabort signal

[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

Il giorno lunedì 11 settembre 2023 alle 11:08:30 UTC+2 TheDiveO ha scritto:

> CMAC_resume might be something from here, IIRC Darwin's OpenBSD anchestry: 
> https://man.openbsd.org/CMAC_Init.3
>
> On Monday, September 11, 2023 at 8:17:44 AM UTC+2 Kurtis Rader wrote:
>
>> On Sun, Sep 10, 2023 at 10:41 PM Danilo bestbug  
>> 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
>>
>

-- 
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/484155ae-394f-4faa-8cb3-225b50ded854n%40googlegroups.com.

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

[TheDiveO]

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

On Monday, September 11, 2023 at 8:17:44 AM UTC+2 Kurtis Rader wrote:

> On Sun, Sep 10, 2023 at 10:41 PM Danilo bestbug  
> 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
>

-- 
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/07e97b35-1bf2-4fe6-b739-7f97ce2fd87fn%40googlegroups.com.

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

[Kurtis Rader]

On Sun, Sep 10, 2023 at 10:41 PM Danilo bestbug <
bestbug.corporat...@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

-- 
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/CABx2%3DD-47%2BOML2hOME2qCXCB3uhcZNt3YJKW5Zb1v1C_zAqVpw%40mail.gmail.com.

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

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

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

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

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

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

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

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

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

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

[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:

> 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 
>>  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/a417062f-ddac-4e64-bbf5-037fcdf64ab6n%40googlegroups.com.

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

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

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

[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?
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
>  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/3a7ac4f8-4623-41d2-8d43-3e134d538c14n%40googlegroups.com.

Re: [go-nuts] x/mobile: avoid to catch sigabort signal

[Ian Lance Taylor]

On Thu, Sep 7, 2023 at 11:41 PM Danilo bestbug
 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/CAOyqgcXYe-n%3DZvF4h5sMJWZO%2BGTYVfMJgvwS-KUPi1yogDyk3g%40mail.gmail.com.

[go-nuts] 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.

-- 
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/2af5c244-f2a5-4808-a393-a699bf376e24n%40googlegroups.com.