Skip Menu |

This queue is for tickets about the Object-Pad CPAN distribution.

Report information
The Basics
Id: 132196
Status: resolved
Priority: 0/
Queue: Object-Pad

People
Owner: Nobody in particular
Requestors: TEAM [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.15
Fixed in: (no value)



Subject: Intermittent segfault in parse_pre_blockend
With a non-trivial class, I can trigger a segfault by changing a line from: method something { } to method something { 123 } however, this failure is intermittent: it sometimes compiles+runs cleanly. (gdb) run Starting program: /home/tom/perl5/perlbrew/perls/perl-5.30.2-debug/bin/perl -Ilib t/redis.t [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. Perl_padname_free (pn=0x41) at pad.c:2790 2790 if (!--PadnameREFCNT(pn)) { (gdb) bt #0 Perl_padname_free (pn=0x41) at pad.c:2790 #1 0x00007ffff566e011 in parse_pre_blockend (body=0x5555565f3f20) at lib/Object/Pad.xs:938 (gdb) frame 1 #1 0x00007ffff566e011 in parse_pre_blockend (body=0x5555565f3f20) at lib/Object/Pad.xs:938 938 PadnameREFCNT_dec(padnames[padix]); Will try to trim down to a minimal test case and attach here. cheers, Tom
The PV looks suspicious: (gdb) p **padnames $5 = {xpadn_pv = 0x0, xpadn_ourstash = 0x5555565e3c30, xpadn_type_u = {xpadn_typestash = 0x5555565e6d40, xpadn_protocv = 0x5555565e6d40}, xpadn_low = 33, xpadn_high = 0, xpadn_refcnt = 1851880056, xpadn_gen = 25959, xpadn_len = 160 '\240', xpadn_flags = 108 'l'} is a null xpadn_pv ever valid?
As of https://metacpan.org/release/PEVANS/Future-AsyncAwait-0.37_003 I'm no longer seeing this segfault, will continue testing but I think this can be closed. Thanks!
On Sun Mar 22 16:32:07 2020, TEAM wrote: Show quoted text
> As of https://metacpan.org/release/PEVANS/Future-AsyncAwait-0.37_003 > I'm no longer seeing this segfault, will continue testing but I think > this can be closed. Thanks!
Was almost certainly the missing `return body` in the function; which amusingly gcc on many platforms didn't warn about, and actually implemented in a way that meant it worked properly anyway. See the 001 -> 002 diff: https://metacpan.org/diff/file?target=PEVANS/Future-AsyncAwait-0.37_002/&source=PEVANS%2FFuture-AsyncAwait-0.37_001 003 seems to pass on all the smokers now anyway. -- Paul Evans