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:52 UTC+2): > On Thu, Sep 17, 2020 at 8:52 AM Tamás Gulácsi <tgula...@gmail.com> 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 wrongly): > https://github.com/godror/godror/blob/2dab250ab19e158ba97699841f40c9de9d061f29/stmt.go#L306 > > > > panic: > https://github.com/godror/godror/issues/100#issuecomment-694192603 > > When a SIGSEGV occurs while running C code called via cgo, that > SIGSEGV is not turned into a Go panic. > > It works this way both because 1) C is not a memory-safe language, and > if the C code has not installed a signal handler there is no reason to > think that the C code is prepared to carry on after a segmentation > violation; 2) the mechanism that Go uses to turn a memory error into a > panic can only work for Go code, not for C code. > > 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/30ca05ec-255b-4d67-b45f-89fde5396bb6n%40googlegroups.com.
