Re: Access violation in SV.C new_body_inline()

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)

Nicholas Clark