Re: Access violation in SV.C new_body_inline()

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 "-M10000000000" "-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 -M10000000000 -e1
> syntax error at -e line 0, near "use 10000000000 ("
> 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
[email protected]
Personal Opinion Only