Thank you very much!
It's way more complicated than I'd to deal with, so I'll leave it as is:
crash the program if the C side gots a SIGSEGV.
Even the gRPC child seems more managable.
Ian Lance Taylor a következőt írta (2020. szeptember 17., csütörtök,
22:11:18 UTC+2):
> On Thu, Sep 17, 2020 at
On Thu, Sep 17, 2020 at 12:09 PM Tamás Gulácsi wrote:
>
> Can you provide some skim of a C-side signal handler that could induce a Go
> panic?
> All I want is to have an error on Go side, instead of a crash (though it may
> be safer to have a crash...).
I can't think of any safe way that a C si
It's very hard to think of a case where a SIGSEGV in a C program could
continue safely. It typically means pointer access out of bounds, which in
turn is usually because some data structure has become corrupted.
My question is, where is this SEGV coming from? Is this a bug in the
Oracle libra
Thanks, absolutely logical.
Can you provide some skim of a C-side signal handler that could induce a Go
panic?
All I want is to have an error on Go side, instead of a crash (though it
may be safer to have a crash...).
Ian Lance Taylor a következőt írta (2020. szeptember 17., csütörtök,
21:00:5
On Thu, Sep 17, 2020 at 8:52 AM Tamás Gulácsi wrote:
>
> I'm searching for help in https://github.com/godror/godror/issues/100 - I've
> added a recover, called debug.SetPanicOnFault, without success: the extra
> free still panics with SIGSEGV, and the recover does not catch it (or I coded
> it
I'm searching for help in https://github.com/godror/godror/issues/100 -
I've added a recover, called debug.SetPanicOnFault, without success: the
extra free still panics with SIGSEGV, and the recover does not catch it (or
I coded it wrongly):
https://github.com/godror/godror/blob/2dab250ab19e15
