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
I've just encountered this in the wild and it took me a long time to realise what was going on. The only obvious failing when you actually run the code is the "panic: XSUB ... failed to extend arg stack", and leads you off in a very wrong path debugging it, when the actual failure is "You built your XS module without -DDEBUGGING and now you're running it with a -DDEBUGGING perl". Surely the presence of -DDEBUGGING ought to be involved in the XS module handshake mechanism, such that a failure of this kind would be much more obviously visible at module load time instead? |
That would break the sort of setup that debian has been using since forever.. |
This allows a debugging perl to be built with the high water mark checks disabled, or a non-debugging perl to be built with the high water marks enabled. This should allow Debian, the reporter for Perl#16607 to build both their normal perl and debugperl with the same state of high water mark checks and avoid the mismatch between a debugperl and non-debug dynamic extension. Fixes Perl#16607
On Mon, Apr 08, 2024 at 01:54:36PM -0700, Leon Timmermans wrote:
> Surely the presence of -DDEBUGGING ought to be involved in the XS
> module handshake mechanism, such that a failure of this kind would be
> much more obviously visible at module load time instead?
That would break the sort of setup that debian has been using since forever..
Just out of curiosity, why is that the case?
…--
"I used to be with it, but then they changed what ‘it’ was, and now what
I’m with isn’t it. And what’s ‘it’ seems weird and scary to me."
-- Grandpa Simpson
(It will happen to you too.)
|
And moreover, how is it that debian's setup doesn't break here? Is there something we could steal from that to make these things work better? |
Looks to me like @tonycoz's solution is the right one. And arguably that |
I do think the HWM checks should be enabled by default for -DDEBUGGING, the checks it performs are just too useful, especially for XS. |
On Tue, Apr 09, 2024 at 03:02:27AM -0700, iabyn wrote:
On Mon, Apr 08, 2024 at 01:54:36PM -0700, Leon Timmermans wrote:
> > Surely the presence of -DDEBUGGING ought to be involved in the XS
> > module handshake mechanism, such that a failure of this kind would be
> > much more obviously visible at module load time instead?
>
> That would break the sort of setup that debian has been using since forever..
Just out of curiosity, why is that the case?
Hi, as I explained in the original submission, 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
(as providing hundreds of debug builds alongside the main ones seems
an obviously bad tradeoff.)
It would be useful for us to keep these builds binary compatible, so that
users could run the -DDEBUGGING build with the normal XS module packages
in the Debian archive when investigating segfaults and the like. This
was the case until Perl 5.28 or so, and based on the earlier discussion
in this ticket we have since been patching the high-water mark checks
away in Debian to keep things so.
Making -DDEBUGGING part of the handshake would improve the failure mode
to provide better diagnostics, but would still mean that debugperl could
not load the modules, and make it even harder for us to patch it. So it
would not solve the underlying issue for us.
Tony's fix in #22131 adds a supported way to disable the checks at the
Configure stage, so we could drop our patch altogether. I'm all for that
of course.
Hope this clarifies,
--
Niko
|
On Tue, Apr 09, 2024 at 03:54:46AM -0700, Paul Evans wrote:
And moreover, how is it that debian's setup doesn't break here? Is there something we could steal from that to make these things work better?
We're just patching the high water checks away currently with
https://salsa.debian.org/perl-team/interpreter/perl/-/blob/debian-5.38/debian/patches/debian/disable-stack-check.diff
Tony's fix in #22131 gives a way to disable them at Configure time,
so it's clearly superior.
--
Niko
|
This allows a debugging perl to be built with the high water mark checks disabled, or a non-debugging perl to be built with the high water marks enabled. This should allow Debian, the reporter for #16607 to build both their normal perl and debugperl with the same state of high water mark checks and avoid the mismatch between a debugperl and non-debug dynamic extension. Fixes #16607
Migrated from rt.perl.org#133327 (status was 'open')
Searchable as RT133327$
The text was updated successfully, but these errors were encountered: