New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stack checks make -DDEBUGGING builds incompatible with normal ones #16607
Comments
From @ntyniThis is a bug report for perl from Niko Tyni <ntyni@debian.org>, The stack 'high water mark' checks introduced in v5.27.1-66-g87058c31e9 We're using this combination in Debian as we offer a -DDEBUGGING It would be useful for us to keep these builds binary compatible. Some symptoms of the breakage: # debugperl -MDateTime -e 'print DateTime->today' # printf '<AAA>\n<DDD/><CCC><DDD>\n</DDD></CCC>\n</AAA>' | debugperl -MXML::LibXML -e 'XML::LibXML->new->parse_f These are just examples, and I believe the fault is not with the If I grok this correctly, the problem is that EXTEND only updates Would it be feasible move the -DDEBUGGING check in EXTEND to run time, Many thanks for your work, and congratulations for another great Perl ( This is also https://bugs.debian.org/902779 ) Flags: Site configuration information for perl 5.28.0: Configured by Debian at Mon Jun 25 19:20:16 UTC 2018. Summary of my perl5 (revision 5 version 28 subversion 0) configuration: Locally applied patches: @INC for perl 5.28.0: Environment for perl 5.28.0: |
From @dur-randirOn Tue, 03 Jul 2018 08:49:38 -0700, ntyni@debian.org wrote:
A lot of module authors use EXTEND pessimistically, like the whole XPUSH* macro family, effectively calling EXTEND in O(return values) number of times. And the suggested approach will surely penalize this. Cpan search showed more than 1000 distribution with this pattern. |
The RT System itself - Status changed from 'new' to 'open' |
From @iabynOn Tue, Jul 03, 2018 at 08:49:39AM -0700, Niko Tyni (via RT) wrote:
I wouldn't like any solution that adds extra run-time overhead to To avoid that, the debugging part of the perl interperter would need to be A fall-back position would be to add support for a PERL_NO_STACK_HWM_CHECK -- |
From @bulk88On Tue, 03 Jul 2018 08:49:38 -0700, ntyni@debian.org wrote:
DEBUGGING is a build option, either the whole interp has it or it doesn't. P5P already questionably added struct fields that are unused on non-DEBUGGING to make DEBUGGING vs not binary compatible but I disagree with that quick fix. Perhaps perl.h should be tweaked to turn on libc assert() without rest of DEBUGGING features and /usr/bin/debugperl should be compiled with that just-libc-assert flag. -- |
From @ntyniOn Wed, Jul 04, 2018 at 05:28:21AM -0700, Dave Mitchell via RT wrote:
I see.
Yeah, I suppose we will have to disable the checks in the Debian Thanks for looking at this, |
Since the interpreter struct is (meant to be) compatible between DEBUGGING and non-DEBUGGING this allows a vendor to build a normal perl and then build a DEBUGGING perl binary compatible with that non-DEBUGGING perl that doesn't panic on the first XS call. Fixes Perl#16607
Migrated from rt.perl.org#133327 (status was 'open')
Searchable as RT133327$
The text was updated successfully, but these errors were encountered: