Mailing List Archive: Perl: porters

5.15.9 breaks Glib (was: Re: 5.15.8: Global destruction phase slow?)

Index | Next | Previous | View Threaded

kaffeetisch at gmx

Mar 21, 2012, 3:12 PM

Post #1 of 4 (95 views)
Permalink

5.15.9 breaks Glib (was: Re: 5.15.8: Global destruction phase slow?)

With perl 5.15.9 (and blead) multiple of Glib's tests segfault. This
reproduces the issue:

use Glib;
my $obj = Glib::Object->new;
$obj->{key} = 'val';

gdb says:

Program received signal SIGSEGV, Segmentation fault.
0x080ed041 in Perl_mg_clear (my_perl=0x81fa008, sv=0x81fe3d0) at mg.c:376
376 if (vtbl && vtbl->svt_clear)
(gdb) bt
#0 0x080ed041 in Perl_mg_clear (my_perl=0x81fa008, sv=0x81fe3d0) at
mg.c:376
#1 0x08107264 in Perl_hv_undef_flags (my_perl=0x81fa008, hv=0x81fe3d0,
flags=2) at hv.c:1872
#2 0x08122976 in Perl_sv_clear (my_perl=0x81fa008, orig_sv=0x81fe3d0)
at sv.c:6294
#3 0x08123146 in Perl_sv_free2 (my_perl=0x81fa008, sv=0x81fe3d0) at
sv.c:6506
#4 0x08129a87 in Perl_sv_unref_flags (my_perl=0x696c6174, ref=0x8217270,
flags=1) at sv.c:9623
#5 0x0811f776 in Perl_sv_force_normal_flags (my_perl=0x81fa008,
sv=0x8217270,
flags=1) at sv.c:4834
#6 0x0814f6e9 in Perl_leave_scope (my_perl=0x81fa008, base=0) at
scope.c:914
#7 0x0814d1ff in Perl_pop_scope (my_perl=0x696c6174) at scope.c:110
#8 0x08158155 in Perl_pp_leave (my_perl=0x81fa008) at pp_ctl.c:2152
#9 0x0810c4e7 in Perl_runops_standard (my_perl=0x81fa008) at run.c:41
#10 0x0807d373 in S_run_body (my_perl=0x81fa008, oldscope=1) at perl.c:2400
#11 0x0807ce5b in perl_run (my_perl=0x81fa008) at perl.c:2318
#12 0x0805d96d in main (argc=2, argv=0xbffff594, env=0xbffff5a0)
at perlmain.c:120

valgrind says:

==26758== Conditional jump or move depends on uninitialised value(s)
==26758== at 0x80ED06B: Perl_mg_clear (mg.c:370)
==26758== by 0x8107263: Perl_hv_undef_flags (hv.c:1872)
==26758== by 0x8122975: Perl_sv_clear (sv.c:6294)
==26758== by 0x8123145: Perl_sv_free2 (sv.c:6506)
==26758== by 0x8129A86: Perl_sv_unref_flags (sv.c:9623)
==26758== by 0x811F775: Perl_sv_force_normal_flags (sv.c:4834)
==26758== by 0x814F6E8: Perl_leave_scope (scope.c:914)
==26758== by 0x814D1FE: Perl_pop_scope (scope.c:110)
==26758== by 0x8158154: Perl_pp_leave (pp_ctl.c:2152)
==26758== by 0x810C4E6: Perl_runops_standard (run.c:41)
==26758== by 0x807D372: S_run_body (perl.c:2400)
==26758== by 0x807CE5A: perl_run (perl.c:2318)
==26758== by 0x805D96C: main (perlmain.c:120)
==26758==
==26758== Use of uninitialised value of size 4
==26758== at 0x80ED02A: Perl_mg_clear (mg.c:371)
==26758== by 0x8107263: Perl_hv_undef_flags (hv.c:1872)
==26758== by 0x8122975: Perl_sv_clear (sv.c:6294)
==26758== by 0x8123145: Perl_sv_free2 (sv.c:6506)
==26758== by 0x8129A86: Perl_sv_unref_flags (sv.c:9623)
==26758== by 0x811F775: Perl_sv_force_normal_flags (sv.c:4834)
==26758== by 0x814F6E8: Perl_leave_scope (scope.c:914)
==26758== by 0x814D1FE: Perl_pop_scope (scope.c:110)
==26758== by 0x8158154: Perl_pp_leave (pp_ctl.c:2152)
==26758== by 0x810C4E6: Perl_runops_standard (run.c:41)
==26758== by 0x807D372: S_run_body (perl.c:2400)
==26758== by 0x807CE5A: perl_run (perl.c:2318)
==26758== by 0x805D96C: main (perlmain.c:120)
==26758==
==26758== Use of uninitialised value of size 4
==26758== at 0x80ED033: Perl_mg_clear (mg.c:374)
==26758== by 0x8107263: Perl_hv_undef_flags (hv.c:1872)
==26758== by 0x8122975: Perl_sv_clear (sv.c:6294)
==26758== by 0x8123145: Perl_sv_free2 (sv.c:6506)
==26758== by 0x8129A86: Perl_sv_unref_flags (sv.c:9623)
==26758== by 0x811F775: Perl_sv_force_normal_flags (sv.c:4834)
==26758== by 0x814F6E8: Perl_leave_scope (scope.c:914)
==26758== by 0x814D1FE: Perl_pop_scope (scope.c:110)
==26758== by 0x8158154: Perl_pp_leave (pp_ctl.c:2152)
==26758== by 0x810C4E6: Perl_runops_standard (run.c:41)
==26758== by 0x807D372: S_run_body (perl.c:2400)
==26758== by 0x807CE5A: perl_run (perl.c:2318)
==26758== by 0x805D96C: main (perlmain.c:120)
==26758==
==26758== Invalid read of size 4
==26758== at 0x80ED041: Perl_mg_clear (mg.c:376)
==26758== by 0x8107263: Perl_hv_undef_flags (hv.c:1872)
==26758== by 0x8122975: Perl_sv_clear (sv.c:6294)
==26758== by 0x8123145: Perl_sv_free2 (sv.c:6506)
==26758== by 0x8129A86: Perl_sv_unref_flags (sv.c:9623)
==26758== by 0x811F775: Perl_sv_force_normal_flags (sv.c:4834)
==26758== by 0x814F6E8: Perl_leave_scope (scope.c:914)
==26758== by 0x814D1FE: Perl_pop_scope (scope.c:110)
==26758== by 0x8158154: Perl_pp_leave (pp_ctl.c:2152)
==26758== by 0x810C4E6: Perl_runops_standard (run.c:41)
==26758== by 0x807D372: S_run_body (perl.c:2400)
==26758== by 0x807CE5A: perl_run (perl.c:2318)
==26758== by 0x805D96C: main (perlmain.c:120)
==26758== Address 0x696c6180 is not stack'd, malloc'd or (recently) free'd
==26758==
==26758==
==26758== Process terminating with default action of signal 11 (SIGSEGV)
==26758== Access not within mapped region at address 0x696C6180
==26758== at 0x80ED041: Perl_mg_clear (mg.c:376)
==26758== by 0x8107263: Perl_hv_undef_flags (hv.c:1872)
==26758== by 0x8122975: Perl_sv_clear (sv.c:6294)
==26758== by 0x8123145: Perl_sv_free2 (sv.c:6506)
==26758== by 0x8129A86: Perl_sv_unref_flags (sv.c:9623)
==26758== by 0x811F775: Perl_sv_force_normal_flags (sv.c:4834)
==26758== by 0x814F6E8: Perl_leave_scope (scope.c:914)
==26758== by 0x814D1FE: Perl_pop_scope (scope.c:110)
==26758== by 0x8158154: Perl_pp_leave (pp_ctl.c:2152)
==26758== by 0x810C4E6: Perl_runops_standard (run.c:41)
==26758== by 0x807D372: S_run_body (perl.c:2400)
==26758== by 0x807CE5A: perl_run (perl.c:2318)
==26758== by 0x805D96C: main (perlmain.c:120)
==26758== If you believe this happened as a result of a stack
==26758== overflow in your program's main thread (unlikely but
==26758== possible), you can try to increase the size of the
==26758== main thread stack using the --main-stacksize= flag.
==26758== The main thread stack size used in this run was 8388608.

(In case you cannot find Glib on CPAN---there's some index issue
currently---you can use
<http://sourceforge.net/projects/gtk2-perl/files/Glib/1.242/Glib-1.242.tar.gz/download>.)

'git bisect' points at the below commit as the culprit.

On 06.03.2012 15:35, Dave Mitchell wrote:
> commit 5bec93bead1c10563a402404de095bbdf398790f
> Author: David Mitchell<davem [at] iabyn>
> AuthorDate: Tue Mar 6 14:26:27 2012 +0000
> Commit: David Mitchell<davem [at] iabyn>
> CommitDate: Tue Mar 6 14:26:27 2012 +0000
>
> fix slowdown in nested hash freeing

davem at iabyn

Mar 26, 2012, 7:01 AM

Post #2 of 4 (80 views)
Permalink

Re: 5.15.9 breaks Glib (was: Re: 5.15.8: Global destruction phase slow?) [In reply to]

On Wed, Mar 21, 2012 at 11:12:00PM +0100, Torsten Schoenfeld wrote:
> With perl 5.15.9 (and blead) multiple of Glib's tests segfault.
> This reproduces the issue:
>
> use Glib;
> my $obj = Glib::Object->new;
> $obj->{key} = 'val';

Fixed now:

commit f37f40f4443470b7a9dc16c4549f9074ff36057b
Author: David Mitchell <davem [at] iabyn>
AuthorDate: Mon Mar 26 13:31:24 2012 +0100
Commit: David Mitchell <davem [at] iabyn>
CommitDate: Mon Mar 26 15:00:03 2012 +0100

clear magic flags in sv_clear

commit 5bec93bead1c10563a402404de095bbdf398790f made temporary use of the
no-longer used SvMAGIC field while freeing a HV. This commit makes
sure that before this happens, that the SvMAGICAL flags are turned off.

This is because it turns out that some XS code (e.g. Glib) can leave an SV
with a null SvMAGIC field, but with magic flags still set.

M sv.c

--
Art is anything that has a label (especially if the label is "untitled 1")

kaffeetisch at gmx

Mar 27, 2012, 11:45 AM

Post #3 of 4 (80 views)
Permalink

Re: 5.15.9 breaks Glib [In reply to]

On 26.03.2012 16:01, Dave Mitchell wrote:
>> use Glib;
>> my $obj = Glib::Object->new;
>> $obj->{key} = 'val';
>
> Fixed now:

Indeed. Thanks a lot!

> This is because it turns out that some XS code (e.g. Glib) can leave an SV
> with a null SvMAGIC field, but with magic flags still set.

Is there something that Glib should do differently? Our current
magic-removal code is here:
<http://git.gnome.org/browse/perl-Glib/tree/GObject.xs#n150>.

davem at iabyn

Apr 1, 2012, 10:12 AM

Post #4 of 4 (73 views)
Permalink

Re: 5.15.9 breaks Glib [In reply to]

On Tue, Mar 27, 2012 at 08:45:45PM +0200, Torsten Schoenfeld wrote:
> On 26.03.2012 16:01, Dave Mitchell wrote:
> > This is because it turns out that some XS code (e.g. Glib) can leave an SV
> > with a null SvMAGIC field, but with magic flags still set.
>
> Is there something that Glib should do differently? Our current
> magic-removal code is here:
> <http://git.gnome.org/browse/perl-Glib/tree/GObject.xs#n150>.

Well ideally it should turn off the magic flags (SvMAGICAL_off(sv))
if there's no magic left.

--
Thank God I'm an atheist.....

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads