Craig A. Berry wrote:
On May 3, 2009, at 9:20 PM, John E. Malmberg wrote:
John E. Malmberg wrote:
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
case SVt_PVMG:
...
new_body_inline(new_body, new_type);
new_type = SVt_PVMG,
SVt_PVMG has a value of 7.
new_body = 44.
PL_Body_roots[sv_type] = 44.
From the code, it looks like this was expected to contain a valid
pointer.
From looking at the source code, it appears that the linked list of
bodies is corrupted. my_perl->Ibodyroots[7] has 44.
Yes, I see the same thing.
I have been looking at the S_more_bodies routine. Would it be
practical to put an assert on for a pointer being added to the linked
list with a value above 512? On VMS, the first page of memory is
protected no access.
I haven't had much time to poke at this, but I think an assert there
would only help if the body is created with a bogus pointer in the
SVt_PVMG slot rather than created with a good pointer that gets
clobbered later, and I think the second explanation is more likely. I
merely observe (without yet a chance fully to pursue) that 44 is a
suspicious number on a couple of different fronts.
Running with -Dm shows that various 44-byte chunks of memory get
allocated, including arenas that are multiples of 44 in size, so if
there is a legitimate size of 44 that is added to something that should
be a good value but is actually NULL, that might be one explanation for
where the bad smell is coming from.
44 / 0x2c is the value of SS$_ABORT, which is the return value of the
system() call in IPC::Cmd::_run, which is called somewhere in the chain
following from CPANPLUS::Dist::_resolve_prereqs.[1] If there is
something inappropriate going on with a vmsish pragma and the return
value of the system() call, that's another place where something could
go wrong, but also as yet another wacky theory that I haven't been able
to prove.
The only way that I can see that being an issue is if the return value
is ever stored in malloc()ed memory, and then either a buffer overrun of
that storage, or that memory gets freed before the status value is written.
Since no one else is reporting this failure, I will start looking at the
VMS specific code for implementing system() so see if I can find anything.
Unfortunately many other things in VMS can return same code, but so far,
that is the best theory I have seen.
If I put some additional checks in SV.c to walk that linked list each
time that routine is called, I may be able to detect the corruption
before the access violation takes place. With the amount of times that
it gets called in perl, this may give us a break, unless it changes
things enough to get hide of the access violation.
I've attached a version of the test script that is slimmed down from
400+ lines to 99 lines but still produces the access violation.
Thanks, I will try that.
[1] IPC::Cmd::_run does not quote arguments, so in its current form
it's not really suitable as a cross-platform way to run Perl
one-liners. For example, when it means to run:
perl "-M100" "-e1"
Perl v1410065408.0.0 required--this is only v5.11.0, stopped.
BEGIN failed--compilation aborted.
%SYSTEM-F-ABORT, abort
it's actually running:
$ perl -M100 -e1
syntax error at -e line 0, near "use 100 ("
Execution of -e aborted due to compilation errors.
%SYSTEM-F-ABORT, abort
So the CPANPLUS::Dist test is not distinguishing between a syntax error
and a version check failure. I don't think it makes any difference for
the access violation, but it's something I noticed while trying to
pursue that.
That probably explains some of the failures besides the access
violation. The other is probably related to a sample file having a '~'
character in the name.
-John
wb8...@qsl.net
Personal Opinion Only
