>>> On 2013/11/24 at 07:15 PM, Torsten Schoenfeld <kaffeeti...@gmx.de> wrote: > 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=1361e9d22763ef008b6f3bcd82ff > eb53c80120c5 >> >> 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.
Sorry late reply. The "fix" though worked for our purposes until now, so that is fine. I build and test Win32 GTK+/Webkit and Gtk-Perl for our center here at the University, so I usually do not want to go to quickly to a newer Perl if not needed. However I have started to at Perl 5.16, but maybe 5.18 will be better? Anyhow, either case except if there are other users with problems, we can just leave as is in my opinion. Any reasons to rather use 5.16 vs 5.18 or reverse would be appreciated. Regards, Martin Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html _______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-perl-list
