Re: Data overrun in Perl_magic_get '?' (Was: Access violation in SV.C new_body_inline())

[email protected] ("Craig A. Berry")
Newsgroups perl.perl5.porters,perl.vmsperl
Message-ID <[email protected]>
On May 18, 2009, at 11:54 PM, John E. Malmberg wrote:

> John E. Malmberg wrote:
>
> The trail has taken me to the following lines just below the comment  
> with the tag AMS 20010810.
>
> while(mg) {
>    const MGVTBL * const vtbl = mg->mg_virtual;
>
>    if (!(mg->mg_flags & MGf_GSKIP) && vtbl && vtbl->svt_get) {
>       CALL_FTPR(vtbl->sv_get)(aTHX_ sv, mg);
>
> On the return from this call, the Ibody_roots[7] is corrupted.
>
> *vtbl-sv_get at this point is loaded with the function  
> Perl_magic_get, and the value it is looking for is the '?'.
>
> And looking there, I find VMS specific code where the my_perl- 
> >Istatusvalue_vms is put into sv->sv_any->slv_targlen.
>
> Istatusvalue_vms contains 44, the same bad pointer value.
>
> The body size for type SVt_PVMG (7) appears to be 32, which means  
> that the LvTARGLEN(sv) writing at offset 32 is the culprit,  
> corrupting the linked list.
>
> I am not sure how to fix this, but now that I have found out this  
> much, maybe someone else here can?



So you're saying that these lines in Perl_magic_get in mg.c:

     case '?':
         {
             sv_setiv(sv, (IV)STATUS_CURRENT);
#ifdef COMPLEX_STATUS
             LvTARGOFF(sv) = PL_statusvalue;
             LvTARGLEN(sv) = PL_statusvalue_vms;
#endif
         }


are where the damage occurs?  So it looks like the SV in question does  
not even have the relevant slots (xlv_targlen) we're trying to update  
here.  I wonder if it's because IPC::Cmd declares $? as local.  Maybe  
we are assuming $? is always lexical but it's not?

________________________________________
Craig A. Berry
mailto:[email protected]

"... getting out of a sonnet is much more
  difficult than getting in."
                  Brad Leithauser
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.