How to print test log in case of failures?

[James Clarke]

On 22 Jan 2018, at 11:34, Gianfranco Costamagna <locutusofborg at debian.org> wrote:
> Hello, I'm trying to sort out an armhf alignment issue
> that happens with haskell-th-utilities in Ubuntu
> (but I'm pretty sure this isn't an Ubuntu-specific issue, reason
> for Ubuntu to fail is probably because stuff is run on top of an arm64
> kernel).
> 
> Test suite logged to: dist-ghc/test/th-utilities-0.2.0.1-test.log
> 0 of 1 test suites (0 of 1 test cases) passed.
> /usr/share/cdbs/1/class/hlibrary.mk:154: recipe for target 'check-ghc-stamp' failed
> make: *** [check-ghc-stamp] Error 1
> 
> this is what is printed.
> 
> Now, how can we print that file in case of failures?
> I tried an override_dh_auto_test but it seems to be a cdbs packaging, and I don't know
> if haskell helpers have some "hooks" to intercept failures
> (it would be even better to patch the build system to automatically print the content
> of the testsuite log in case of failures BTW)
> 
> If you are interested, this is the log
> https://launchpad.net/ubuntu/+source/haskell-th-utilities/0.2.0.1-1build1/+build/13678151
> 
> Any help is appreciated :)
> 
> (I'm ccing James, since he knows a lot on this aligment/topic :) )

It's reproducible on amdahl in the sid_armhf-dchroot chroot. The log file
doesn't have any more information:

> Test suite test: RUNNING...
> Test suite test: FAIL
> Test suite logged to: dist-ghc/test/th-utilities-0.2.0.1-test.log

However, running the same command as the build but with --verbose, i.e.
debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct --verbose,
shows that dist-ghc/build/test/test is being run. Running this gives a Bus
error, and under gdb:

> Program received signal SIGBUS, Bus error.                                                                                        
> 0x00010b8c in cqDA_info$def ()
> (gdb) bt
> #0  0x00010b8c in cqDA_info$def ()
> #1  0xf742324c in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) disas
> Dump of assembler code for function cqDA_info$def:
>    0x00010b84 <+0>:     ldrd    r0, [r7, #3]
>    0x00010b88 <+4>:     ldr     r7, [r5, #4]
> => 0x00010b8c <+8>:     strd    r0, [r7, #5]
>    0x00010b90 <+12>:    movw    r7, #39312      ; 0x9990
>    0x00010b94 <+16>:    ldr     r0, [r5, #12]!
>    0x00010b98 <+20>:    movt    r7, #189        ; 0xbd
>    0x00010b9c <+24>:    add     r7, r7, #1
>    0x00010ba0 <+28>:    bx      r0
> End of assembler dump.
> (gdb) p/x $r7
> $1 = 0xf742324c

So, yeah, $r7+0x5 doesn't look very aligned to me, and although Armv7 (and v8)
support unaligned accesses, they only guarantee to do so for up to 32-bit
values (or at least, that's what GCC assumes on Armv7), but STRD is a 64-bit
store. Looking at the local .o files, cqDA_info$def is coming from
dist-ghc/build/test/test-tmp/TH/Derive/StorableSpec.o, i.e.
test/TH/Derive/StorableSpec.hs, but given all the peek/poke/castPtr operations
are in src/TH/Derive/Storable.hs, I assume it's really something that's been
inlined. That whole file looks like a major source of unaligned accesses, at a
glance, and likely needs some attention to support a potential lack of 64-bit
(and, in general, any) unaligned accesses.

Regards,
James