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
>
