develooper Front page | perl.perl5.porters | Postings from October 2013

Padlist NULL pointer?

Thread Next
From:
Darin McBride
Date:
October 30, 2013 04:32
Subject:
Padlist NULL pointer?
Message ID:
1507776.GJWKRtZUpe@naboo
Short version:

Under what conditions, if any, can a pad pointer be allocated (in padlist) but 
be NULL in 5.18+?

Long version:

I have a stack of 160+ CPAN modules installed identically under both perl 
5.16.3 and 5.18.1, with a segfault in Perl_pad_push only under 5.18.1.

This segfault is both consistent (as in, I have a non-trivial test case that 
can expose it every time) and not (as in, if I make a small change, such as 
introducing an extra class to my Moose hierarchy, the seg fault goes away).

I've compiled both perls both with and without -DDEBUGGING.  The seg faults 
always occur on 5.18.1, regardless of DEBUGGING, and never on 5.16.3.

When I bring it up in gdb, I find the crash is on this line:

	SV** const oldpad = AvARRAY(svp[depth-1]);

What I've noticed is that depth is 8, and svp[7] is 0x0.  So, unsurprisingly, 
this crashes.  But then the question is, why is it allocated (within 
PadlistMAX(padlist) ), but NULL?

The C call stack at this point includes a number of functions from Coro, and 
the perl call stack includes various Moose and Try::Tiny functions, as well as 
my own.  However, as I've said, this all works with exactly the same code, 
merely substituting perl 5.16.3 for 5.18.1.  I'm just looking for where a 
patch may be required to stop the seg fault.  For example, I'm not sure if 
Perl_pad_push should be a bit more defensive and automatically skip NULL 
pointers at the end of the padlist, moving back until the first non-NULL.  Or 
if there is a reason why this change in 5.18 means that Coro simply needs to 
keep up.

Thanks!
Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About