Re: Access violation in SV.C new_body_inline()

Nicholas Clark wrote:
> On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
>> I just started looking into a failure of 19_CPANPLUS-Dist.  I have not 
>> determined what exactly is wrong, and am out of time for the moment.
>>
>> I will try to get some more information later.
>>
>> It is failing from an access violation in SV.C.
>>
>> ok 57 -    Perl version not high enough
>> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual 
>> address=000000000000002C, PC=00000000000F9AB8, PS=0000001B
>> %TRACE-F-TRACEBACK, symbolic stack dump follows
>>   image    module    routine             line      rel PC
>> abs PC
>>  DBGPERLSHR  SV  Perl_sv_upgrade        73671 0000000000001F58 
>> 00000000000F9AB8
>>  DBGPERLSHR  SV  Perl_sv_setsv_flags    76204 000000000000AC88 
>> 00000000001027E8
> 
>> EAGLE> search [-]sv.lis/window=10 73671
>>       2   73667         /* We always allocated the full length item 
>> with PURIFY.
>>  To do this
>>       2   73668            we fake things so that arena is false for 
>> all 16 type
>> s..  */
>>       3   73669         if(new_type_details->arena) {
>>       3   73670             /* This points to the start of the 
>> allocated area.
>> */
>>       3   73671             new_body_inline(new_body, new_type);
> 
> #define new_body_inline(xpv, sv_type) \
>     STMT_START { \
> 	void ** const r3wt = &PL_body_roots[sv_type]; \
> 	xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt))      \
> 	  ? *((void **)(r3wt)) : more_bodies(sv_type)); \
> 	*(r3wt) = *(void**)(xpv); \
>     } STMT_END
> 
> I'm curious what the value of sv_type is. It's the second (real) parameter:
> 
> void
> 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.

Looking at the source, the Macro PURIFY is not defined. 
new_body_inline() was invoked there with the same arguments, yet here it 
did not access violate.

Looking at sv->sv_any, it contains 0 at the time of the access violation.

At the time of the access violation, new_type_details->offset is 0.

If I set the breakpoints closer to where the access violation occurs, I 
do not see an access violation.  In the past, when that happens, it 
indicates an uninitialized variable.

Regards,
-John
[email protected]
Personal Opinion Only