So I'm working on a GTK3 module (finally). This will be a little different and
use gobject introspection to call methods by name, dynamically, so I won't have
to write code to interface with every single function. The module will use
gobject introspection to look up the method by the object
OK, that's clear.
> 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
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
2018-05-25 11:06 GMT+02:00 Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @
Pike (-) developers forum <10...@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 t
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.
Documentation of signal
https://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/signal.html
says:
"Although it IS possible to trap SIGBUS, SIGSEGV etc, I advise you not to;
Pike should not receive any such signals, and if it does, it is because of
bugs in the Pike interpreter"
Should
