Re: Bug#501825: libjson-xs-perl_2.23-1(sparc/unstable): FTBFS on sparc, fails in tests

[Julien Cristau <jcristau@debian.org>]

On Wed, Oct 15, 2008 at 23:39:52 +0300, Niko Tyni wrote:

> This is reproducible on sperger.d.o.
> 
> It's an alignment problem that only shows up with an optimization level
> of at least -O2.
> 
> Program received signal SIGBUS, Bus error.
> 0xf7ec1134 in decode_json (string=0x192280, json=0x39f18, offset_return=0xff85b96c) at XS.xs:1443
> 1443      SvGROW (string, SvCUR (string) + 1); // should basically be a NOP
> (gdb) bt
> #0  0xf7ec1134 in decode_json (string=0x192280, json=0x39f18, offset_return=0xff85b96c) at XS.xs:1443
> #1  0xf7ec2444 in XS_JSON__XS_incr_parse (my_perl=0x22008, cv=0x126d58) at XS.xs:1828
> #2  0xf7dfab48 in Perl_pp_entersub () from /usr/lib/libperl.so.5.10
> #3  0xf7df8f9c in Perl_runops_standard () from /usr/lib/libperl.so.5.10
> #4  0xf7df4298 in perl_run () from /usr/lib/libperl.so.5.10
> #5  0x00010b88 in main ()
> 
> The instruction that causes the bus error is a double-word load (ldd):
> 
> 0xf7ec1130 <decode_json+132>:   ld  [ %l1 ], %g1
> 0xf7ec1134 <decode_json+136>:   ldd  [ %g1 + 8 ], %g2
> 0xf7ec1138 <decode_json+140>:   inc  %g2
> 0xf7ec113c <decode_json+144>:   cmp  %g3, %g2
> 
> The preprocessor output for the above SvGROW() macro invocation is
> 
>   (((XPV*) (string)->sv_any)->xpv_len < (((XPV*) (string)->sv_any)->xpv_cur + 1) ? Perl_sv_grow(((PerlInterpreter *)pthread_getspecific((*Perl_Gthr_key_ptr(((void *)0))))), string,((XPV*) (string)->sv_any)->xpv_cur + 1) : ((string)->sv_u.svu_pv));
> 
> and the above assembly is the compiled form of the first comparison
> at -O2.  The compiler is using a double-word instruction to load both
> xpv_cur and xpv_len in one go.
> 
> Now, this apparently requires that ((XPV*) (string)->sv_any)->xpv_cur
> is aligned on a double-word (64-bit) boundary, which fails here:
> 
[...]
> 
> This suggests to me that gcc is being too aggressive on optimizing here.
> I don't see how it can consider the double word instruction safe.
> 
__alignof__(XPV) is 8, so gcc is allowed to assume that any XPV is
64-bit aligned, as far as I can tell.  xpv_cur's offset is 8, so it
should also be 64-bit aligned.

Cheers,
Julien