On 11.07.2012 17:55, Martin Schlemmer wrote: >> This is with Gtk3::WebKit and HTTP:Soup (so assume mostly G-O-I perl >> objects): >> >> Over here it only reaches it only once as well, but the SV is not valid >> (another crash when I try to dump it), so I assume the SV was already freed, >> but not the qdata for the SoupSession GObject? >> >> Side note, Glib-1.240 crash outside GDB, while inside it runs fine, >> Glib-1.260 >> trigger a segfault inside GDB as well. > > Firstly, this works fine with AS Perl 5.16.0. > > Trying to track this down (AS Perl 5.14.2 MSWin32-x86), I looked at: > > http://git.gnome.org/browse/perl-Glib/commit/?id=1361e9d22763ef008b6f3bcd82ffeb53c80120c5 > > and modified Glib-1.261's gobject_destroy_wrapper() to add back: > > ----- > - if (PL_in_clean_objs) > - return; > ----- > > Now it (see attached example) started to work like 1.240 where it would be > fine running from GDB, but segfaults outside, so I rebuilt it with -DNOISY > and got the backtrace below (let me know if I should send logs from -DNOISY > as well).
I've taken another look at this. I've boiled down the test program down to what is attached. I can confirm that under perl 5.14.4 this program usually crashes at exit and that valgrind reports lots of incorrect memory accesses. For perl >= 5.16, everything seems to be fine. Looking at the backtraces you provided and the ones I get from gdb, I now realize that the problem with perl 5.14.4 is that our gobject_destroy_wrapper() is called from a program exit handler installed by WebKit. These are run when the perl interpreter is about to exit, i.e. way after it has already torn down all of its internal structure. Thus, even something like PL_in_clean_objs is unreliable (and accesses invalid memory). I also verified that the same kind of erroneous behavior occurs without the change cited above that removed the PL_in_clean_objs branch from gobject_destroy_wrapper(). So this is not a regression. This does not happen with perl >= 5.16 due to its increased diligence in object destruction. It finds the detached HV and destroys it during perl's global destruction phase, thus cutting the link between the long-lived GObject and perl. When the program exit handler from WebKit then runs, no call back into gobject_destroy_wrapper() happens. So we would need a way to reliably detect in gobject_destroy_wrapper() when we are called from a program exit handler. The only thing I can think of is to install our own program exit handler that sets a global boolean. But I'm reluctant to do that since it would probably come with portability issues. Unless there are better suggestions, I think we just need to accept this wart.
ref-count-test.pl
Description: Perl program
_______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
