develooper Front page | perl.perl5.porters | Postings from September 2012

Re: unhappy darwin -Dusemorebits (was Re: Smoke [5.17.4]v5.17.3-184-g699aa44 FAIL(F) darwin 12.1.0 (Intel Core 2 Duo/))

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
September 1, 2012 13:21
Subject:
Re: unhappy darwin -Dusemorebits (was Re: Smoke [5.17.4]v5.17.3-184-g699aa44 FAIL(F) darwin 12.1.0 (Intel Core 2 Duo/))
Message ID:
20120901200510.GA2913@iabyn.com
On Sat, Sep 01, 2012 at 03:34:34PM +0100, Nicholas Clark wrote:
> On Sun, Sep 02, 2012 at 12:14:47AM +1000, Tony Cook wrote:
> 
> > 1..16
> > ==73082== 
> > ==73082== Process terminating with default action of signal 11 (SIGSEGV)
> > ==73082==  General Protection Fault
> > ==73082==    at 0x1000D9DD3: Perl_sv_force_normal_flags (sv.c:9505)
> > ==73082==    by 0x1000E6147: Perl_sv_setsv_flags (sv.c:3910)
> > ==73082==    by 0x1000C9BDF: Perl_pp_sassign (pp_hot.c:212)
> > ==73082==    by 0x10009EA8A: Perl_runops_debug (dump.c:2134)
> > ==73082==    by 0x100026E77: perl_run (perl.c:2392)
> > ==73082==    by 0x100001779: main (perlmain.c:114)
> > ==73082== 
> > 
> >     if(SvTYPE(sv) == SVt_PVGV) {
> >         /* need to keep SvANY(sv) in the right arena */
> >         xpvmg = new_XPVMG();
> > -->     StructCopy(SvANY(sv), xpvmg, XPVMG);
> >         del_XPVGV(SvANY(sv));
> >         SvANY(sv) = xpvmg;
> > 
> >         SvFLAGS(sv) &= ~SVTYPEMASK;
> >         SvFLAGS(sv) |= SVt_PVMG;
> >     }
> > 
> > (gdb) print sv->sv_any
> > $3 = (void *) 0x1008cc118
> > 
> > rip is 0x1000d9dd3
> > 
> > 0x00000001000d9dcf <Perl_sv_force_normal_flags+1263>:   mov    0x0(%r13),%rcx
> > -->0x00000001000d9dd3 <Perl_sv_force_normal_flags+1267>:   movaps (%rcx),%xmm0
> > 0x00000001000d9dd6 <Perl_sv_force_normal_flags+1270>:   movaps 0x10(%rcx),%xmm1
> > 0x00000001000d9dda <Perl_sv_force_normal_flags+1274>:   movaps 0x20(%rcx),%xmm2
> > 0x00000001000d9dde <Perl_sv_force_normal_flags+1278>:   movaps 0x30(%rcx),%xmm3
> > 0x00000001000d9de2 <Perl_sv_force_normal_flags+1282>:   movaps %xmm3,0x30(%rax)
> > 0x00000001000d9de6 <Perl_sv_force_normal_flags+1286>:   movaps %xmm2,0x20(%rax)
> > 0x00000001000d9dea <Perl_sv_force_normal_flags+1290>:   movaps %xmm1,0x10(%rax)
> > 0x00000001000d9dee <Perl_sv_force_normal_flags+1294>:   movaps %xmm0,(%rax)
> 
> OK, thanks. I don't know any x86_64 assembler, nor do I know its alignment
> constrains or whatnot, so I'm not able to work out from this what went
> wrong. And whether it's us doing something dodgy or them.

See http://www.damtp.cam.ac.uk/cosmos/private/documentation/vtune/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/instruct32_hh/vc181.htm

(fond from google search).

movaps basically copies a 16-byte check to/from one of FPU registers; the
data must be 16-byte aligned. From ther above, sv_any is only 8-byte
alignegned

On my Linux system, the line
    StructCopy(SvANY(sv), xpvmg, XPVMG);
is expanded to 
    (*((XPVMG*)(xpvmg)) = *((XPVMG*)((sv)->sv_any)));

So, struct xpvgv's are being allocated on 8-byte boundaries within the arena,
yet the compiler assumes the structure is 16-byte aligned. After that I get
confused.

PS the structure (xpvmg and xpvgv) expand as

    ptr
    ptr/STRLEN
    STRLEN/I32
    ptr/IV/UV
    NV/ptr/{U32,U32}/{I32,U8}

where the / show different elements of a union



> 
> Nicholas Clark

-- 
Gravity is just a theory; teach Intelligent Falling in our schools!
    http://www.theonion.com/content/node/39512

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About