Re: [perl.git] branch blead, updated. v5.13.1-179-g2116934

On Sun, Jun 13, 2010 at 03:31:23PM +0100, Dave Mitchell wrote:
> On Sun, Jun 13, 2010 at 09:52:23AM +0200, Nicholas Clark wrote:
> >     In pp_eof, ensure stack space for the second argument to the tied EOF method.
> >     
> 
> Are you finding these via visual inspection?

Yes. And I *think* that my changes are correct, but it's the same me visually
inspecting them (at least) twice, not an independent inspection, or a different
analysis method.

> This leads to to wonder whether we could automate it?

Yes, I was wondering this too.

> Something along the lines of, for debugging builds, alter the sp
> manipulation macros in pp to initially record the high-water mark of the
> stack, increase that mark whenever the  code calls EXTEND etc,
> and complain if sp is ever incremented above it; e.g.:
> 
> 
> #define dSP       SV **sp = PL_stack_sp; SV** sp_hwm = sp;
> 
> #define EXTEND    { ........ ; sp_hwm = sp; }
> 
> #define PUSHs(s)  { if (sp >= sp_hwm) croak(...); *++sp = (s)) }

I was wondering about something like that. And also resetting the high water
mark to the last used entry in the runloop between each op, to force the
issue.

Or by aggressively using realloc() to shrink the stack, and letting valgrind
do the bounds checking. Possibly also making a new -D flag, so that they can
be enabled as desired at runtime.

However, I'm not certain whether some of the code is "legal", in that
certain ops are always preceded by certain other ops, and the preceding ops
have always extended the stack to be large enough. But even if that is the
case in practice, it would scare me that we're relying on the current
structures produced by the current parser/code generator.


I'm still chewing over what might be the best way to do this, so if you want
to beat me to an implementation, that's fine, and won't be duplicate effort.

Nicholas Clark