Bug#902779: perl-debug: XS code built for perl doesn't work with debugperl

[Niko Tyni]

Control: block 902557 with -1

On Sat, Jun 30, 2018 at 10:06:34PM +0300, Niko Tyni wrote:
> Package: perl-debug
> Version: 5.28.0-1
> Severity: normal
> User: debian-perl at lists.debian.org
> Usertags: perl-5.28-transition
> 
> I noticed that many of our XS module packages are incompatible
> with debugperl after being rebuilt for 5.28. Consider:
> 
>  # debugperl -MDateTime -e 'print DateTime->today'
>  panic: XSUB DateTime::_rd2ymd (DateTime.c) failed to extend arg stack: base=55b63e6b3b48, sp=55b63e6b3b80, hwm=55b63e6b3b68
> 
> This panic is due to a new -DDEBUGGING check that guards the XS function
> argument stack, making sure that XS code extends the stack properly when
> it pushes elements there.
> 
> However, I believe the check isn't currently working properly when
> the XS code is built with a non-DDEBUGGING perl.h and then run with a
> -DDEBUGGING perl build.

So, I see the EXTEND macro in pp.h is instrumented to make a note of
how far the stack is supposed to extend, and this 'high-water mark'
(hwm) is compared to the stack pointer after calling an XSUB. If the
XSUB has pushed more elements than it declared with EXTEND (or didn't
call EXTEND at all), the above panic will result.

The problem is that EXTEND only updates the high-water mark when the
DEBUGGING preprocessor symbol is defined (i.e. the choice is done at
compile time.) If the XS module is built without -DDEBUGGING in ccflags
(as is the case for Debian XS module packages), the high-water mark
doesn't get updated.  If the interpreter side is built with -DDEBUGGING
(as our debugperl is), it will still check the hwm.

I see two obvious avenues for fixing this:

A) move the -DDEBUGGING check in EXTEND to run time, for instance by
   calling a function that's a no-op in non-DEBUGGING interpreters. This
   has a runtime cost, but I'm not sure how significant. We need to ask
   upstream.

B) disable the check on the DEBUGGING side altogether. There's currently
   no facility to do this short of patching the code.

If A) is judged adequate upstream, we should do that before the 5.28
transition so that we don't have to rebuild all the XS modules afterwards.
I'm therefore marking this as a transition blocker for now.

Otherwise we need to do B) and lose some useful debugging checks.
-- 
Niko Tyni   ntyni at debian.org