Re: Glib 1.261 and ref counting with perl 5.14

On 2013/11/24 at 07:15 PM, Torsten Schoenfeld <kaffeetisch 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 

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, 
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: 

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.


Vrywaringsklousule / Disclaimer: 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]