On Tue, Jul 03, 2018 at 08:49:39AM -0700, Niko Tyni (via RT) wrote: > The stack 'high water mark' checks introduced in v5.27.1-66-g87058c31e9 > seem to have introduced an incompatibility when XS modules are built > with a normal Perl but run with a (otherwise similarly configured) > -DDEBUGGING Perl. > > We're using this combination in Debian as we offer a -DDEBUGGING > interpreter (called /usr/bin/debugperl) in a separate package for the > benefit of our users, but we don't rebuild all the XS modules with that. [snip] > If I grok this correctly, 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, resulting in the panic. > > Would it be feasible move the -DDEBUGGING check in EXTEND to run time, > for instance by calling a function that's a no-op in non-DEBUGGING > interpreters, or checking for an interpreter variable that's only set > in -DDEBUGGING builds? This has a runtime cost, but I'm not sure how > significant that is? I wouldn't like any solution that adds extra run-time overhead to non-debugging-build XS modules. To avoid that, the debugging part of the perl interperter would need to be able to determine when it calls an XS sub or a non-core pp_foo() function, whether that code what compiled under DEBUGGING. I can't think of a way to determine this. A fall-back position would be to add support for a PERL_NO_STACK_HWM_CHECK define / build option which would completely disable checks, even if the core was built with DEBUGGING. That would of course disable the check even for XS modules built with DEBUGGING. -- Overhead, without any fuss, the stars were going out. -- Arthur C ClarkeThread Previous | Thread Next