Front page | perl.perl5.porters |
Postings from September 2012
On Sat, Sep 1, 2012 at 9:34 AM, Nicholas Clark <nick@ccl4.org> 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.
>
> Is anyone else able to work backwards from this to what the cause is?
Apple gcc contrary to the default or homebrew gcc defaults to 16bit
stack alignment for performance reasons and easier SSE interaction.
Similar to Sun cc.
Normally this should do no harm, unless you mix non-apple cc compiled
code or if you change struct alignment manually. Or if you mix cflags.
Our StructCopy relies on the compiler struct copy, which should work ok.
In this case:
movaps (%rcx),%xmm0
rcx is not properly aligned (0 as first char). SSE code requires 16
bit alignment.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
BTW: The normal behaviour should be SIGBUS not SIGSEGV,
but gcc is different.
Unfortunately I gave my darwin pc away, so I cannot single step
through it.
If it's not one of these causes I would say it's one of these nasty
compiler bugs, and I would use the old-style StructCopy with this
config.
Or compile with -mno-sse
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
Thread Previous
|
Thread Next