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
multiconcat breaks blead on VMS #16219
Comments
From @craigberryCurrently (v5.27.5-183-g78a6433791) miniperl is unable to run ConfigPM on VMS in a default configuration, which of course means blead does not build. Switching to -Duse64bitint (which is not the default) makes it work for some reason. Seems to happen with or without -DDEBUGGING. Whittling down ConfigPM to the offending line, I eventually ended up with a reproducer that looks like, in Unix parlance: ./miniperl -Ilib -e 'my $s; $s .= q||;' but below is how it looks on VMS with Perl's -Dt output and the VMS debugger output mixed together: $ MCR []dbgminiperl.exe "-I[.lib]" -"Dt" -e "my $s; $s .= q||;" OpenVMS I64 Debug64 Version V8.4-001 %DEBUG-I-INITIAL, Language: C, Module: MINIPERLMAIN DBG> go EXECUTING... (-e:0) enter A "reason mask" of 04 in an access violation means it's trying to write to memory to which it does not have access, in this case the stack pointer: DBG> examine/hex sp I can't provide the output of perl -V since Config is not successfully built. Here are the config args: $ search config.sh config_args I will try to think of what else to poke at over the next day or two, but something seems to have clobbered the sp pointer, which is written to via the SETTARG macro in Perl_pp_multiconcat. ________________________________________ "... getting out of a sonnet is much more |
From @craigberryOn Thu, Nov 2, 2017 at 10:57 PM, Craig A.Berry
I started looking at Perl_pp_multiconcat and don't claim to understand SP -= (nargs - 1); which, when nargs is zero, actually adds to the stack pointer rather |
The RT System itself - Status changed from 'new' to 'open' |
From @iabynOn Fri, Nov 03, 2017 at 04:16:57PM -0500, Craig A. Berry wrote:
Yes, that's intentional. Zero args are are passed on the stack, but if (!nargs) -- |
From @nwc10On Thu, Nov 02, 2017 at 08:57:05PM -0700, Craig A.Berry wrote:
Neither ASAN nor valgrind, for both x86 or x86_54, for threaded and unthreaded
However, I'm not familiar enough with what VMS defaults to (eg threading or Although that's more "for the benefit of others" because I don't really have Nicholas Clark |
From @craigberry
Thanks. I had seen that EXTEND and wondered why it didn't do anything (never calls Perl_stack_grow). It thinks it already has enough stack space: stepped to PP_HOT\Perl_pp_multiconcat\%LINE 181635 So it appears that the stack we think we have isn't actually writable. I guess it's time for a visit to Perl_init_stacks. |
From @craigberry
Thanks for poking at this.
The following is perl -V from the commit immediately preceding e839e6e, "Add OP_MULTICONCAT op" but in the same configuration. $ perl -"V" Characteristics of this PERLSHR image:
I hacked miniperl to eliminate what gets loaded by buildcustomize.pl: Inline Patch--- perlmini.c;-0 2017-11-01 22:40:54 -0500
+++ perlmini.c 2017-11-03 07:02:59 -0500
@@ -2247,7 +2247,7 @@ S_parse_body(pTHX_ char **env, XSINIT_t
AV *const inc = GvAV(PL_incgv);
SV **const inc0 = inc ? av_fetch(inc, 0, FALSE) : NULL;
- if (inc0) {
+ if (0) {
/* if lib/buildcustomize.pl exists, it should not fail. If it does,
it should be reported immediately as a build failure. */
(void)Perl_av_create_and_unshift_one(aTHX_ &PL_preambleav,
which skips some platform-specific code, but that made no difference. So if it's something platform-specific, I haven't found it. I suppose it could also be some unusual combination of intsize, longsize, ptrsize, alignbytes and friends that isn't common elsewhere. |
From @craigberry
I configured on macOS Sierra (10.12.6) like so: $ ./Configure -Dusedevel -DDEBUGGING -Uuse64bitint -des (hmm, Configure ignored the -Uuse64bitint -- I guess 32-bit support is gone on this platform) and that gives me: $ ./miniperl -Dst -e 'my $s; $s .= q||;' EXECUTING... => whereas on VMS I get: $ MCR []miniperl.exe -"Dst" -e "my $s; $s .= q||;"' EXECUTING... => which as far as I can see is exactly the same until it dies. It falls down so hard that it doesn't even signal the crash unless I run it under the debugger and explicitly ask it to break on exceptions. |
From @nwc10On Sat, Nov 04, 2017 at 10:25:42AM -0500, Craig A. Berry wrote:
Which made me try it on what I guessed was the most alignment-grumpy machine Sadly I don't have access to anything Sparc (and more) as that was always But no, still can't replicate. I did wonder - if you run ./miniperl -Dst -e 'my $s; $s .= q||;' (And I got rid of the -Ilib - I think that that is about the same as your Nicholas Clark |
From @iabynOn Sat, Nov 04, 2017 at 03:53:33PM -0500, Craig A. Berry wrote:
I'd suggest expand out these macro calls in pp_multiconcat: EXTEND(SP,1); into theie constituent parts (on separate lines if necessary), then PS - the -f option to miniperl stops it loading buildcustomize.pl (or -- |
From @craigberry
I have done so. sp and PL_stack_sp are equal to each other and are unchanged by the EXTEND. The only effect of the EXTEND is that PL_curstackinfo->si_stack_hwm gets bumped from 0 to 1. The only thing SETTARG does is: (*sp = targ); which on Itanium is the single instruction: st4 [r51] = targ and that's where it blows up, flagging the value of sp as an address that can't be written to. But it can be: I can readily execute a deposit command in the debugger that does the same thing as that statement and it works just fine. So I think there's something else hosed up and sp (in this case register 51) is just the last thing it knew about at the time of the exception. AND, I've now tried it on Alpha with the same configuration and there is no problem there. So only Itanium has the problem. At the moment it's looking like more of a C stack corruption, but who knows. And that's the end of my weekend debugging time.
Good to know. |
From @craigberryOn Sun, Nov 5, 2017 at 6:19 PM, Craig A. Berry <craigberry@mac.com> wrote:
I've now finally gotten back to this and the fix is easy: Inline Patch--- pp_hot.c;-0 2017-11-04 06:24:52 -0500
+++ pp_hot.c 2017-11-09 20:41:41 -0600
@@ -391,7 +391,7 @@ PP(pp_multiconcat)
UNOP_AUX_item *aux; /* PL_op->op_aux buffer */
UNOP_AUX_item *const_lens; /* the segment length array part of aux */
const char *const_pv; /* the current segment of the const string buf */
- UV nargs; /* how many args were expected */
+ IV nargs; /* how many args were expected; IV
The rationale for that fix is a bit harder, but before I get into Where things go wrong for the C compiler is at the line: SP -= (nargs - 1); when the unsigned nargs is zero. The C++ compiler, which on OpenVMS I64 is a completely unrelated targ = SP[-nargs]; In both of these cases, the target of the assignment is a 32-bit %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual because 0x017DBAA4 is the correct address of sp and I ignored the I assume we are running aground on some interpretation of C99 6.2.5, I'm having trouble wrapping my head around how you can represent a [1] https://stackoverflow.com/questions/8026694/c-unary-minus-operator-behavior-with-unsigned-operands |
From @khwilliamsonOn 11/10/2017 07:59 AM, Craig A. Berry wrote:
ilmari found some bugs in multiconcat in regard to this, and is smoking https://perl5.git.perl.org/perl.git/shortlog/refs/heads/smoke-me/ilmari/multiconcat-fix |
From @craigberry
Thanks, but VMS is little endian and sizeof(UV) and sizeof(size_t) are both 4 bytes in the configurations relevant to this ticket, so I think that's actually an unrelated problem. |
From @maukeAm 10.11.2017 um 15:59 schrieb Craig A. Berry:
That's easy: We're talking about "the largest value that can be Example: Assume unsigned int is 16 bits wide and therefore UINT_MAX = In other words, unsigned integer overflow is guaranteed to wrap around (Signed integer overflow has undefined behavior. This does not mean you This has been today's episode of: Fun with Standard C. -- |
From @iabynOn Fri, Nov 10, 2017 at 08:59:56AM -0600, Craig A. Berry wrote:
I've now pushed a more general fix: commit ca84e88 change OP_MULTICONCAT nargs from UV to SSize_t -- |
From @craigberryOn Nov 13, 2017, at 06:37 AM, Dave Mitchell <davem@iabyn.com> wrote: On Fri, Nov 10, 2017 at 08:59:56AM -0600, Craig A. Berry wrote: I've now finally gotten back to this and the fix is easy: Inline Patch--- pp_hot.c;-0 2017-11-04 06:24:52 -0500
+++ pp_hot.c 2017-11-09 20:41:41 -0600
@@ -391,7 +391,7 @@ PP(pp_multiconcat)
I've now pushed a more general fix: commit ca84e88 change OP_MULTICONCAT nargs from UV to SSize_t Change it from unsigned to unsigned since it makes the SP-adjusting code Thanks. That got things building again and I think this ticket can be closed. |
@iabyn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#132390 (status was 'resolved')
Searchable as RT132390$
The text was updated successfully, but these errors were encountered: