Re: efl FTBFS on mipsel (SIGBUS-related testsuite failure)

[Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>]

Albin Tonnerre <lutin@debian.org> writes:

> Hi,

Hi,
>
> I've been trying to debug a testsuite issue on mipsel that causes an
> FTBFS for the `efl` package
> (https://buildd.debian.org/status/fetch.php?pkg=efl&arch=mipsel&ver=1.8.3-1&stamp=1389324403),
> but I can't seem to find the actual cause of the issue.
>
> Essentially what the test does is mmap() a file and access it. The
> code installs a signal handler to catch a possible SIGBUS when
> accessing the mmap'ed region and handle it when it happens. Running a
> simple testcase in GDB (see attached log file) shows that the program
> generates a SIGBUS at a valid address, but it looks like once the
> signal handler is called, siginfo->si_addr is 0 and I don't really
> understand why.

>From a _very_ quick look:
eet_dictionary_string_get_double (ed=0x45de80, idx=<optimized out>,
result=0x468bec) at lib/eet/eet_dictionary.c:460
460        *result = convert->d;
(gdb) info registers
          zero       at       v0       v1       a0       a1       a2
          a3
 R0   00000000 1000a4e1 00000004 80100000 0045de90 00000000 00000000
 7efefeff
            t0       t1       t2       t3       t4       t5       t6
            t7
 R8   77fe32e4 0fffffff 77b9f730 f0000000 00000000 00000000 00000004
 7ffe9ba8
            s0       s1       s2       s3       s4       s5       s6
            s7
 R16  0045de90 00468bec 00469040 00000000 00000168 00000010 769f4c68
 004380c8
            t8       t9       k0       k1       gp       sp       s8
            ra
 R24  00000067 77e8d630 769fa930 00000000 77a4f290 7ffe9d50 7ffe9f48
 77a20788
        status       lo       hi badvaddr    cause       pc
      0000a4f3 00001cb2 000001a2 00468bec 10000014 77a29214
          fcsr      fir  restart
      00800004 00000501 00000000
(gdb) disass 0x77a29214,+1
Dump of assembler code from 0x77a29214 to 0x77a29215:
=> 0x77a29214 <eet_dictionary_string_get_double+204>:   sdc1 $f0,0(s1)

so it's using sdc1 with 0(s1). s1 contains 0x00468bec. Oops. iirc sdc1
requires the data to be aligned on 8 [1] and clearly s1 is not, so you're
getting a SIGBUS. That's all I can say but I hope it'll help you a
little (I'm even wondering why sdc1 is used but well, it's getting late
here so I'm probably missing something).


Arnaud

[1] to be clearer, all double pointers should be aligned on 8.