Bug#847397: libimager-perl FTBFS on mips/mipsel: Failed 10/66 test programs

Thu Dec 8 23:14:23 UTC 2016

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   ntyni at debian.org