Bleadperl recently introduced a new SEGV #13637

p5pRT · 2014-03-03T04:56:37Z

Migrated from rt.perl.org#121362 (status was 'resolved')

Searchable as RT121362$

p5pRT · 2014-03-03T04:56:37Z

From @andk

v5.19.9-64-g111f73b was the first perl on which I noticed a segv while
running the tests of RJBS/Number-Tolerant-1.703.tar.gz

It's not bisectable because it's intermittent.

(gdb) bt
#0 malloc_consolidate (av=av@entry=0x2b1a68423640 <main_arena>)
at malloc.c:4094
#1 0x00002b1a680f8d77 in _int_malloc (av=0x2b1a68423640 <main_arena>,
bytes=4080) at malloc.c:3379
#2 0x00002b1a680fb083 in __GI___libc_malloc (bytes=4080) at malloc.c:2859
#3 0x000000000048ab42 in Perl_safesysmalloc (size=size@entry=4080)
at util.c:130
#4 0x00000000004b0a57 in Perl_more_bodies (my_perl=my_perl@entry=0x13ab010,
sv_type=sv_type@entry=SVt_PVGV, body_size=body_size@entry=48,
arena_size=arena_size@entry=4080) at sv.c:1059
#5 0x00000000004b8084 in Perl_sv_upgrade (my_perl=my_perl@entry=0x13ab010,
sv=sv@entry=0x1e91cd8, new_type=new_type@entry=SVt_PVGV) at sv.c:1364
#6 0x000000000043dd37 in Perl_gv_init_pvn (my_perl=my_perl@entry=0x13ab010,
gv=gv@entry=0x1e91cd8, stash=stash@entry=0x1e913f0,
name=name@entry=0x14c74d0 "intersection", len=len@entry=12,
flags=flags@entry=2) at gv.c:366
#7 0x000000000044146a in Perl_gv_fetchmeth_pvn (
my_perl=my_perl@entry=0x13ab010, stash=stash@entry=0x1e913f0,
name=name@entry=0x14c74d0 "intersection", len=len@entry=12,
level=level@entry=0, flags=flags@entry=768) at gv.c:700
#8 0x000000000043ed3f in Perl_gv_fetchmethod_pvn_flags (
my_perl=my_perl@entry=0x13ab010, stash=stash@entry=0x1e913f0,
name=0x14c74d0 "intersection", len=<optimized out>, flags=768) at gv.c:1002
#9 0x000000000043f195 in Perl_gv_fetchmethod_sv_flags (
my_perl=my_perl@entry=0x13ab010, stash=0x1e913f0,
namesv=namesv@entry=0x1791f60, flags=<optimized out>, flags@entry=768)
at gv.c:935
#10 0x00000000004a7e37 in S_method_common (my_perl=my_perl@entry=0x13ab010,
meth=meth@entry=0x1791f60, hashp=hashp@entry=0x7fff44c4c62c)
at pp_hot.c:3081
#11 0x00000000004b03e7 in Perl_pp_method_named (my_perl=0x13ab010)
at pp_hot.c:2961
#12 0x00000000004a7ae6 in Perl_runops_standard (my_perl=0x13ab010) at run.c:42
#13 0x00000000004427e1 in Perl_amagic_call (my_perl=my_perl@entry=0x13ab010,
left=left@entry=0x13d8088, right=<optimized out>, right@entry=0x13d81a8,
method=method@entry=46, flags=0) at gv.c:3254
#14 0x0000000000443a33 in Perl_try_amagic_bin (
my_perl=my_perl@entry=0x13ab010, method=method@entry=46,
flags=flags@entry=4) at gv.c:2742
#15 0x00000000004cea8a in Perl_pp_bit_and (my_perl=0x13ab010) at pp.c:2183
#16 0x00000000004a7ae6 in Perl_runops_standard (my_perl=0x13ab010) at run.c:42
#17 0x000000000043cb84 in S_run_body (oldscope=1, my_perl=0x13ab010)
at perl.c:2449
#18 perl_run (my_perl=0x13ab010) at perl.c:2365
#19 0x000000000041bdcb in main (argc=2, argv=0x7fff44c4ca08,
env=0x7fff44c4ca20) at perlmain.c:112

--
andreas

p5pRT · 2014-03-03T16:47:13Z

From @khwilliamson

On 03/02/2014 09:56 PM, (Andreas J. Koenig) (via RT) wrote:

# New Ticket Created by (Andreas J. Koenig)
# Please include the string: [perl #121362]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=121362 >

v5.19.9-64-g111f73b was the first perl on which I noticed a segv while
running the tests of RJBS/Number-Tolerant-1.703.tar.gz

It's not bisectable because it's intermittent.

(gdb) bt
#0 malloc_consolidate (av=av@entry=0x2b1a68423640 <main_arena>)
at malloc.c:4094
#1 0x00002b1a680f8d77 in _int_malloc (av=0x2b1a68423640 <main_arena>,
bytes=4080) at malloc.c:3379
#2 0x00002b1a680fb083 in __GI___libc_malloc (bytes=4080) at malloc.c:2859
#3 0x000000000048ab42 in Perl_safesysmalloc (size=size@entry=4080)
at util.c:130
#4 0x00000000004b0a57 in Perl_more_bodies (my_perl=my_perl@entry=0x13ab010,
sv_type=sv_type@entry=SVt_PVGV, body_size=body_size@entry=48,
arena_size=arena_size@entry=4080) at sv.c:1059
#5 0x00000000004b8084 in Perl_sv_upgrade (my_perl=my_perl@entry=0x13ab010,
sv=sv@entry=0x1e91cd8, new_type=new_type@entry=SVt_PVGV) at sv.c:1364
#6 0x000000000043dd37 in Perl_gv_init_pvn (my_perl=my_perl@entry=0x13ab010,
gv=gv@entry=0x1e91cd8, stash=stash@entry=0x1e913f0,
name=name@entry=0x14c74d0 "intersection", len=len@entry=12,
flags=flags@entry=2) at gv.c:366
#7 0x000000000044146a in Perl_gv_fetchmeth_pvn (
my_perl=my_perl@entry=0x13ab010, stash=stash@entry=0x1e913f0,
name=name@entry=0x14c74d0 "intersection", len=len@entry=12,
level=level@entry=0, flags=flags@entry=768) at gv.c:700
#8 0x000000000043ed3f in Perl_gv_fetchmethod_pvn_flags (
my_perl=my_perl@entry=0x13ab010, stash=stash@entry=0x1e913f0,
name=0x14c74d0 "intersection", len=<optimized out>, flags=768) at gv.c:1002
#9 0x000000000043f195 in Perl_gv_fetchmethod_sv_flags (
my_perl=my_perl@entry=0x13ab010, stash=0x1e913f0,
namesv=namesv@entry=0x1791f60, flags=<optimized out>, flags@entry=768)
at gv.c:935
#10 0x00000000004a7e37 in S_method_common (my_perl=my_perl@entry=0x13ab010,
meth=meth@entry=0x1791f60, hashp=hashp@entry=0x7fff44c4c62c)
at pp_hot.c:3081
#11 0x00000000004b03e7 in Perl_pp_method_named (my_perl=0x13ab010)
at pp_hot.c:2961
#12 0x00000000004a7ae6 in Perl_runops_standard (my_perl=0x13ab010) at run.c:42
#13 0x00000000004427e1 in Perl_amagic_call (my_perl=my_perl@entry=0x13ab010,
left=left@entry=0x13d8088, right=<optimized out>, right@entry=0x13d81a8,
method=method@entry=46, flags=0) at gv.c:3254
#14 0x0000000000443a33 in Perl_try_amagic_bin (
my_perl=my_perl@entry=0x13ab010, method=method@entry=46,
flags=flags@entry=4) at gv.c:2742
#15 0x00000000004cea8a in Perl_pp_bit_and (my_perl=0x13ab010) at pp.c:2183
#16 0x00000000004a7ae6 in Perl_runops_standard (my_perl=0x13ab010) at run.c:42
#17 0x000000000043cb84 in S_run_body (oldscope=1, my_perl=0x13ab010)
at perl.c:2449
#18 perl_run (my_perl=0x13ab010) at perl.c:2365
#19 0x000000000041bdcb in main (argc=2, argv=0x7fff44c4ca08,
env=0x7fff44c4ca20) at perlmain.c:112

Often, these kind of errors are found by running valgrind.
Porting/bisect.pl has an option to bisect those:

# When did this test program start generating errors from valgrind?
* .../Porting/bisect.pl --valgrind ../test_prog.pl

p5pRT · 2014-03-03T16:47:14Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2014-03-03T21:39:01Z

From @andk

Karl Williamson <public@khwilliamson.com> writes:

Often, these kind of errors are found by running valgrind.

Maybe it's this, starting with v5.19.9-63-g3d147ac when running
t/union_more.t in Number-Tolerant-1.703:

==4659== Invalid read of size 4
==4659== at 0x441DC5: Perl_Gv_AMupdate (gv.c:2616)
==4659== by 0x44240D: Perl_amagic_call (gv.c:2865)
==4659== by 0x443A32: Perl_try_amagic_bin (gv.c:2742)
==4659== by 0x4CEB98: Perl_pp_bit_or (pp.c:2213)
==4659== by 0x4A7AE5: Perl_runops_standard (run.c:42)
==4659== by 0x43CB83: perl_run (perl.c:2449)
==4659== by 0x41BDCA: main (perlmain.c:112)
==4659== Address 0x7cb6ad4 is 180 bytes inside a block of size 184 free'd
==4659== at 0x4C2B7AE: realloc (vg_replace_malloc.c:687)
==4659== by 0x48AFB9: Perl_safesysrealloc (util.c:244)
==4659== by 0x49FEA2: S_hsplit (hv.c:1179)
==4659== by 0x4A34DC: Perl_hv_common (hv.c:870)
==4659== by 0x4A416D: Perl_hv_common_key_len (hv.c:336)
==4659== by 0x441385: Perl_gv_fetchmeth_pvn (gv.c:693)
==4659== by 0x43ED3E: Perl_gv_fetchmethod_pvn_flags (gv.c:1002)
==4659== by 0x43F194: Perl_gv_fetchmethod_sv_flags (gv.c:935)
==4659== by 0x442009: Perl_Gv_AMupdate (gv.c:2566)
==4659== by 0x44240D: Perl_amagic_call (gv.c:2865)
==4659== by 0x443A32: Perl_try_amagic_bin (gv.c:2742)
==4659== by 0x4CEB98: Perl_pp_bit_or (pp.c:2213)
==4659==

But I get a lot of other output from valgrind that looks alarming also
with other bleadperls. So if the above doesn't guide you, feel free to
guide me.

--
andreas

p5pRT · 2014-03-03T21:58:33Z

From @nwc10

Dave...

On Mon, Mar 03, 2014 at 10:27:40PM +0100, Andreas Koenig wrote:

Karl Williamson <public@khwilliamson.com> writes:

Often, these kind of errors are found by running valgrind.

Maybe it's this, starting with v5.19.9-63-g3d147ac when running
t/union_more.t in Number-Tolerant-1.703:

==4659== Invalid read of size 4
==4659== at 0x441DC5: Perl_Gv_AMupdate (gv.c:2616)
==4659== by 0x44240D: Perl_amagic_call (gv.c:2865)
==4659== by 0x443A32: Perl_try_amagic_bin (gv.c:2742)
==4659== by 0x4CEB98: Perl_pp_bit_or (pp.c:2213)
==4659== by 0x4A7AE5: Perl_runops_standard (run.c:42)
==4659== by 0x43CB83: perl_run (perl.c:2449)
==4659== by 0x41BDCA: main (perlmain.c:112)
==4659== Address 0x7cb6ad4 is 180 bytes inside a block of size 184 free'd
==4659== at 0x4C2B7AE: realloc (vg_replace_malloc.c:687)
==4659== by 0x48AFB9: Perl_safesysrealloc (util.c:244)
==4659== by 0x49FEA2: S_hsplit (hv.c:1179)
==4659== by 0x4A34DC: Perl_hv_common (hv.c:870)
==4659== by 0x4A416D: Perl_hv_common_key_len (hv.c:336)
==4659== by 0x441385: Perl_gv_fetchmeth_pvn (gv.c:693)
==4659== by 0x43ED3E: Perl_gv_fetchmethod_pvn_flags (gv.c:1002)
==4659== by 0x43F194: Perl_gv_fetchmethod_sv_flags (gv.c:935)
==4659== by 0x442009: Perl_Gv_AMupdate (gv.c:2566)
==4659== by 0x44240D: Perl_amagic_call (gv.c:2865)
==4659== by 0x443A32: Perl_try_amagic_bin (gv.c:2742)
==4659== by 0x4CEB98: Perl_pp_bit_or (pp.c:2213)
==4659==

That will be a subtle bug that we all missed in 3d147ac

The aux structure is stored after the hash's array. The array is getting
reallocated on a split. Hence the (cached) pointer to the aux structure in
Perl_Gv_AMupdate() is stale. I don't have time in the near future to attempt
a fix, or audit for similar possibilities with taking pointers to aux
structures. Sorry.

Nicholas Clark

p5pRT · 2014-03-03T23:32:22Z

From @khwilliamson

On 03/03/2014 02:27 PM, Andreas Koenig wrote:

But I get a lot of other output from valgrind that looks alarming also
with other bleadperls. So if the above doesn't guide you, feel free to
guide me.

Please send the alarming things to this list, so we can see what else is
problematic.

p5pRT · 2014-03-04T08:07:13Z

From @andk

Karl Williamson <public@khwilliamson.com> writes:

On 03/03/2014 02:27 PM, Andreas Koenig wrote:

But I get a lot of other output from valgrind that looks alarming also
with other bleadperls. So if the above doesn't guide you, feel free to
guide me.

Please send the alarming things to this list, so we can see what else
is problematic.

It turned out it's the linux dynaloader that causes the base noise, so
nothing in perl itself. The other thing of interest I found in perl has
just got a separate perlbug (#121373)

--
andreas

p5pRT · 2014-03-04T19:16:41Z

From @iabyn

On Mon, Mar 03, 2014 at 09:58:01PM +0000, Nicholas Clark wrote:

That will be a subtle bug that we all missed in 3d147ac

The aux structure is stored after the hash's array. The array is getting
reallocated on a split. Hence the (cached) pointer to the aux structure in
Perl_Gv_AMupdate() is stale. I don't have time in the near future to attempt
a fix, or audit for similar possibilities with taking pointers to aux
structures. Sorry.

Thanks for the diagnosis . Fixed with 4547997.

--
In economics, the exam questions are the same every year.
They just change the answers.

p5pRT · 2014-03-04T23:28:41Z

@iabyn - Status changed from 'open' to 'resolved'

p5pRT · 2014-03-07T17:55:14Z

From @iabyn

On Tue, Mar 04, 2014 at 07:16:14PM +0000, Dave Mitchell wrote:

On Mon, Mar 03, 2014 at 09:58:01PM +0000, Nicholas Clark wrote:

That will be a subtle bug that we all missed in 3d147ac

The aux structure is stored after the hash's array. The array is getting
reallocated on a split. Hence the (cached) pointer to the aux structure in
Perl_Gv_AMupdate() is stale. I don't have time in the near future to attempt
a fix, or audit for similar possibilities with taking pointers to aux
structures. Sorry.

Thanks for the diagnosis . Fixed with 4547997.

And I've now audited core for similar possible situations with
339441e

--
But Pity stayed his hand. "It's a pity I've run out of bullets",
he thought. -- "Bored of the Rings"

p5pRT closed this as completed Mar 4, 2014

p5pRT added the Severity Low label Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bleadperl recently introduced a new SEGV #13637

Bleadperl recently introduced a new SEGV #13637

p5pRT commented Mar 3, 2014

p5pRT commented Mar 3, 2014

p5pRT commented Mar 3, 2014

p5pRT commented Mar 3, 2014

p5pRT commented Mar 3, 2014

p5pRT commented Mar 3, 2014

p5pRT commented Mar 3, 2014

p5pRT commented Mar 4, 2014

p5pRT commented Mar 4, 2014

p5pRT commented Mar 4, 2014

p5pRT commented Mar 7, 2014

Bleadperl recently introduced a new SEGV #13637

Bleadperl recently introduced a new SEGV #13637

Comments

p5pRT commented Mar 3, 2014

p5pRT commented Mar 3, 2014

From @andk

p5pRT commented Mar 3, 2014

From @khwilliamson

p5pRT commented Mar 3, 2014

p5pRT commented Mar 3, 2014

From @andk

p5pRT commented Mar 3, 2014

From @nwc10

p5pRT commented Mar 3, 2014

From @khwilliamson

p5pRT commented Mar 4, 2014

From @andk

p5pRT commented Mar 4, 2014

From @iabyn

p5pRT commented Mar 4, 2014

p5pRT commented Mar 7, 2014

From @iabyn