Try running that test with valgrind, it should tell you more reliably what the issue is. You will either have to compile pike --with-valgrind or use --smc-check=all so that valgrind is able to deal with the generated machine code. Another useful valgrind option is --track-origin=yes, which will try to tell you e.g. where undefined values came from and more info about the origin of things on the heap.
arne
On 03/02/16 21:48, Chris Angelico wrote:
int main() { GTK2.setup_gtk(); object btn=GTK2.Button("Raise an exception"); object win=GTK2.Window(0)->add(btn)->show_all(); win->signal_connect("destroy",lambda() {exit(0);}); btn->signal_connect("clicked",lambda() {error("Baboom!\n");}); return -1; }
Run this, click the button, then close the window. Pike will segfault.
Running a --with-debug Pike under gdb shows that the actual segfault occurs in backend_callback (defined in GTK2/source/global.pre), where it calls into the low end main loop for an iteration. Not immediately helpful.
I suspect that something's getting corrupted - maybe in the Pike stack, maybe something gets freed in GTK that should have another reference - when the exception happens. How can I go about tracking this down? Where would I put probes to watch for unexpected changes?
ChrisA