TL;dr: this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
On Thu, Dec 08, 2016 at 08:07:23PM +0100, gregor herrmann wrote: > On Thu, 08 Dec 2016 09:11:51 +1100, Tony Cook wrote: > > > > https://buildd.debian.org/status/package.php?p=libimager-perl&suite=sid > > > > > > ... > > > Test Summary Report > > > ------------------- > > > t/150-type/030-double.t (Wstat: 10 Tests: 16 Failed: 0) > > > Non-zero wait status: 10 > > > Parse errors: Bad plan. You planned 136 tests but ran 16. > > > > This looks like an unaligned access from the tests that failed, > > probably in imgdouble.c. > > > > Would it be possible to get access to this (or similar) hardware to > > debug on? > > Difficult :/ There's https://dsa.debian.org/doc/guest-account/ FWIW. But yes, rather onerous. > > Otherwise a backtrace for a -g build from the crash would be handy: > > > > perl Makefile.PL OPTIMIZE=-g It goes away without the default optimization level -O2. On eller.debian.org, mipsel chroot, with OPTIMIZE="-g -O2": ok 14 - - got right color (99, 0) ok 15 - - got right color (0, 100) ok 16 - - got right color (99, 100) Program received signal SIGBUS, Bus error. 0x77cc099c in i_glinf_ddoub (im=0x55774788, l=<optimized out>, r=<optimized out>, y=<optimized out>, vals=0x5577d0b0) at imgdouble.c:280 280 vals[i].channel[ch] = ((double *)im->idata)[off]; (gdb) bt #0 0x77cc099c in i_glinf_ddoub (im=0x55774788, l=<optimized out>, r=<optimized out>, y=<optimized out>, vals=0x5577d0b0) at imgdouble.c:280 #1 0x77c68678 in XS_Imager_i_glinf (my_perl=0x5575d008, cv=<optimized out>) at Imager.xs:3771 #2 0x55636f30 in Perl_pp_entersub (my_perl=0x5575d008) at pp_hot.c:3987 #3 0x5562db20 in Perl_runops_standard (my_perl=0x5575d008) at run.c:41 #4 0x5559c92c in S_run_body (oldscope=1, my_perl=0x5575d008) at perl.c:2488 #5 perl_run (my_perl=0x5575d008) at perl.c:2411 #6 0x5556cce0 in main (argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at perlmain.c:116 (gdb) p i $1 = 0 (gdb) p ch $2 = 1 (gdb) p off $3 = 0 Everything looks 8-byte aligned to me: (gdb) p &(vals[i].channel[ch]) $4 = (i_fsample_t *) 0x5577d0b8 (gdb) p &(((double *)im->idata)[off]) $5 = (double *) 0x77c1c008 Getting desperate enough to disassemble: (gdb) disassemble Dump of assembler code for function i_glinf_ddoub: 0x77cc091c <+0>: bltz a3,0x77cc09c8 <i_glinf_ddoub+172> 0x77cc0920 <+4>: nop 0x77cc0924 <+8>: lw v0,8(a0) 0x77cc0928 <+12>: slt v0,a3,v0 0x77cc092c <+16>: beqz v0,0x77cc09c8 <i_glinf_ddoub+172> 0x77cc0930 <+20>: nop 0x77cc0934 <+24>: lw v0,4(a0) 0x77cc0938 <+28>: slt v1,a1,v0 0x77cc093c <+32>: beqz v1,0x77cc09c8 <i_glinf_ddoub+172> 0x77cc0940 <+36>: nop 0x77cc0944 <+40>: bltz a1,0x77cc09c8 <i_glinf_ddoub+172> 0x77cc0948 <+44>: slt t3,v0,a2 0x77cc094c <+48>: lw v1,0(a0) 0x77cc0950 <+52>: movn a2,v0,t3 0x77cc0954 <+56>: move t3,a2 0x77cc0958 <+60>: mul a2,a3,v0 0x77cc095c <+64>: subu t3,t3,a1 0x77cc0960 <+68>: addu a3,a2,a1 0x77cc0964 <+72>: blez t3,0x77cc09d0 <i_glinf_ddoub+180> 0x77cc0968 <+76>: mul a3,a3,v1 0x77cc096c <+80>: lw t2,16(sp) 0x77cc0970 <+84>: move v0,zero 0x77cc0974 <+88>: blez v1,0x77cc09b4 <i_glinf_ddoub+152> 0x77cc0978 <+92>: nop 0x77cc097c <+96>: sll t0,a3,0x3 0x77cc0980 <+100>: move a2,zero 0x77cc0984 <+104>: subu t0,t0,t2 0x77cc0988 <+108>: move a1,t2 0x77cc098c <+112>: lw v1,32(a0) 0x77cc0990 <+116>: addiu a2,a2,1 0x77cc0994 <+120>: addu v1,v1,a1 0x77cc0998 <+124>: addiu a1,a1,8 => 0x77cc099c <+128>: ldxc1 $f0,v1(t0) 0x77cc09a0 <+132>: sdc1 $f0,-8(a1) 0x77cc09a4 <+136>: lw v1,0(a0) 0x77cc09a8 <+140>: slt t1,a2,v1 0x77cc09ac <+144>: bnez t1,0x77cc098c <i_glinf_ddoub+112> 0x77cc09b0 <+148>: addiu a3,a3,1 0x77cc09b4 <+152>: addiu v0,v0,1 0x77cc09b8 <+156>: bne t3,v0,0x77cc0974 <i_glinf_ddoub+88> 0x77cc09bc <+160>: addiu t2,t2,32 0x77cc09c0 <+164>: jr ra 0x77cc09c4 <+168>: nop 0x77cc09c8 <+172>: jr ra 0x77cc09cc <+176>: move v0,zero 0x77cc09d0 <+180>: jr ra 0x77cc09d4 <+184>: move v0,t3 End of assembler dump. This seems to be the toolchain problem described at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176 as the underlying host here is also a 64-bit one and the conditions match: (gdb) p /x $t0 $7 = 0xaa882f50 (gdb) p /x $v1 $8 = 0xcd3990b8 (gdb) p /x $t0 + $v1 $9 = 0x77c1c008 FWIW building with gcc-5 works fine and passes all the tests. The disassembled code there uses ldc1 not ldxc1. Unfortunately gcc doesn't seem to have a targeted option to disable this optimization. Building with -O0 on mips and mipsel is probably the best workaround we have (-O1 isn't enough.) -- Niko Tyni nt...@debian.org