2018-05-25 11:06 GMT+02:00 Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se:
The latter. Basically, there is no legitimate reason for pike code to trap these signals since there should be nothing pike code can do that cause these signals to be fired.
Right. But when I include some library which corrupts memory into Pike build or make changes to Pike sourcecode itself, then it is possible to crash Pike and then trapping SIGSEGV can bring in additional information about probable place where the memory corruption occurred. Is my understanding correct?
If you are looking for bugs in libraries or in Pike itself, I would recommend running pike in gdb and letting it catch the SIGSEGV. Or, if it is not practical to run with gdb attached for whatever reason, use gdb with the resulting core-dump to perform a post mortem. gdb will give you much better information than a simple signal handler could hope to do.
Right. But when I include some library which corrupts memory into Pike build or make changes to Pike sourcecode itself, then it is possible to crash Pike and then trapping SIGSEGV can bring in additional information about probable place where the memory corruption occurred. Is my understanding correct?
Not really. You won't be able to get any especially useful information about the low-level stuff from Pike code, and there's no telling what broke where, so you won't even know if the Pike core is still working or if it was somehow corrupted by memory overwrites or something. Getting a core file and inspecting it afterwards with GDB will probably be more useful.
pike-devel@lists.lysator.liu.se
-
Leif Stensson, Lysator ＠ Pike developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Tomasz Jamroszczak