Front page | perl.perl5.porters |
Postings from October 2013
On Wed, Oct 30, 2013 at 10:39:35AM +0000, Zefram <zefram@fysh.org> wrote:
> >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 representation of pads changed substantially in 5.18. Chances are
> that the nullness is an interaction between the new pad system and
> Coro's dynamic stack swapping, for which Coro will need an update.
I can't imagine this to be the case, i.e. Coro somehow introducing a null
pointer anywhere.
I also see in the code of Perl_pad_push that it does handle 0 pad
pointers, as long as they are for pads not in use, so something in Perl
(or a module that isn't Coro) seems to replace pointers by 0 somewhere.
> You'll need to apply a debugger to figure out exactly how you get to
> the crashing state, and how it differs from 5.16.
5.16 differs in that all pad pointers between 2 and max are != 0. It also
differs in that pad_push doesn't support 0 pointers, so some of the changes
in the pad system must have made this legal somewhere.
Since I don't really like blindly applying patches, does anybody in p5p
udnerstand where 0-pad pointers are introduced, and point me at it so I cna
understand what actually happens?
Being able to maintain coro myself would doubtlessly be good for everybody
:)
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
Thread Previous
|
Thread Next