Re: Access violation in SV.C new_body_inline()

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.

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.


[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.

________________________________________
Craig A. Berry
mailto:[email protected]

"... getting out of a sonnet is much more
  difficult than getting in."
                  Brad Leithauser