phobos2-test-runner (1.5.0) fails on armv7l (RPI2): _Unwind_RaiseException failed with reason code: 9

[deviator]

Hello. I download latest prebuild version of ldc and try to run test on target platform:

druntime-test-runner-debug

pass all tests but
Not safe to migrate Fibers between Threads on your system. Consider setting version CheckFiberMigration for this system in thread.d

druntime-test-runner

pass all tests but same warning as in debug version

phobos2-test-runner-debug

show stack after pass std.socket

/lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0x0)[0x76d8c6c0]
/lib/arm-linux-gnueabihf/libpthread.so.0(pthread_join+0x10)[0x76efd358]
./phobos2-test-runner-debug(_D4core6thread6Thread4joinMFbZC6object9Throwable+0x2c)[0x4cd9ff8]
./phobos2-test-runner-debug(_D3std11parallelism18_sharedStaticDtor9FZ14__foreachbody1MFKC4core6thread6ThreadZi+0x88)[0x41cd110]
./phobos2-test-runner-debug(_D4core6thread6Thread7opApplyFMDFKC4core6thread6ThreadZiZi+0x7c)[0x4cdaa38]
... 120 (!) identical lines ...
./phobos2-test-runner-debug(_D4core6thread6Thread7opApplyFMDFKC4core6thread6ThreadZiZi+0x7c)[0x4cdaa38]
****** FAIL release32 std.stdio
core.exception.AssertError@std/stdio.d(1452): Fork crashed
----------------
exception.d:455 onAssertErrorMsg [0x4cd332f]
exception.d:632 _d_assert_msg [0x4cd394b]
stdio.d:1452 void std.stdio.File.__unittestL1430_12().runForked(void delegate()) [0x47aace3]
stdio.d:1458 void std.stdio.File.__unittestL1430_12() [0x47aaa97]
... 120 identical lines too ...
stdio.d:1458 void std.stdio.File.__unittestL1430_12() [0x47aaa97]

Other tests passed

phobos2-test-runner

after pass std.process show this

Fatal error in EH code: _Unwind_RaiseException failed with reason code: 9
Aborted

Same error I have in random places in my program what compiled by all previous version of ldc that I tried
forum thread
if run phobos2-test-runner under gdb it show this stack trace

4.035s PASS release32 std.process
Fatal error in EH code: _Unwind_RaiseException failed with reason code: 9

Thread 1 "phobos2-test-ru" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x76d93824 in __GI_abort () at abort.c:89
#2  0x04715d48 in fatalerror ()
#3  0x0470b3b8 in _d_assert ()
#4  0x03e6828c in std.random.__unittestL3012_44() ()
#5  0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

If I understood correctly this is code generation problem and not related to frontend.

host

Linux 4.13.10-200.fc26.x86_64

ldc from prebuild

LDC - the LLVM D compiler (1.5.0):
  based on DMD v2.075.1 and LLVM 5.0.0
  built with LDC - the LLVM D compiler (1.5.0)
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake

build tests

env CC=/usr/bin/arm-linux-gnueabihf-gcc ldc-build-runtime --testrunners -j8 --dFlags='-mtriple=arm-linux-gnueabihf' TARGET_SYSTEM="Linux;UNIX" BUILD_SHARED_LIBS=OFF

cross-linker

arm-linux-gnueabihf-gcc (GCC) 7.2.0

target RPI2 with official raspbian stretch with desktop

Linux 4.9.41-v7+ #1023

[kinke]

I ran the unittests in the QEMU ARMv7l emulator too (after compiling them natively in the emulator on Debian Jessie, no cross-compilation), only issue was std.random in release mode IIRC (edit: confirmed, I still have a log file) - that's your failing test after std.process - with Fatal error in EH code: _Unwind_RaiseException failed with reason code: 9, which has been around for quite some time now (latest summary: #2024 (comment)).

[kinke]

So it'd be interesting to know whether your std.stdio really consistently fails in debug mode (phobos2-test-runner-debug std.stdio) as I haven't had that issue.

[deviator]

So it'd be interesting to know whether your std.stdio really consistently fails in debug mode (phobos2-test-runner-debug std.stdio) as I haven't had that issue.

Yes, in debug and release fails with error core.exception.AssertError@std/stdio.d(1452): Fork crashed

I try to build with -mtriple=armv7l-linux-gnueabihf -march=cortex-a7 and run test and have no _Unwind_RaiseException error. Is this mean that problem solved in my case (RPI2)? Or this problem can raise in other place?

[deviator]

but if I set -march=cortex-a7 in .ldc/ldc2.conf I have error that cortex-a7 are not supported...

[kinke]

cortex-a7 is a CPU (-mcpu=cortex-a7 if you really want to target it specifically). Just use the triple and try to avoid -march (especially in combination with a full triple), it's very inflexible (e.g., you can't choose armv7 there, just arm) and tends to confuse people.

[deviator]

tends to confuse people

sorry.

it's very inflexible

in my case I have unstable soft on device what must work 24/7 and doesn't matter what it can be inflexible... I want to my device work perfect) or at worst it did not have problems like this...

as a result I can try use for my RPI2
-mcpu=cortex-a7 -march=arm -mattr=+strict-align,-neon
without triple, right?

that flags I must use for my RPI2 cortex-a7 cpu with linux?

[kinke]

I'd use -mtriple=armv7l-linux-gnueabihf -mcpu=cortex-a7 then. The triple includes, among other things, the exact architecture, so no need for -march, and -mcpu tailors the machine-codegen for that CPU, so you don't/shouldn't need -mattr.

[joakim-noah]

We cannot debug your errors without more info, eg a sample that we can reproduce or something else. The fact that most of the stdlib tests pass for you suggests it may not be a problem with the compiler, but something wrong with your own code.

That issue in std.random is stack corruption related to inlining a test that catches an exception, an ARM codegen issue that we haven't tracked down yet. It is basically the only remaining ARM issue in the testsuite.

Do you catch a lot of exceptions in your own code that's failing, perhaps inlined? You can try building your project with -disable-inlining and see if it makes a difference. You can still have the code be optimized with -O3 or whatever you're using now, which normally will automatically inline, but this flag will disable inlining regardless.

Let us know what you find. As I noted in that forum thread, we can't help you without more info.

[joakim-noah]

Regarding the std.stdio crash, can you just try running that module's tests alone, with ./phobos2-test-runner std.stdio? I found that made the crash go away when I tried it, likely because of some interaction with some other stdlib module tested, maybe the static constructors. As I noted in the linked comment, that's an upstream dmd bug that comes and goes for ldc, which our CI doesn't hit because it always specifies the module to be tested and so doesn't run all of the modules' tests at once.

[deviator]

@joakim-noah

Regarding the std.stdio crash, can you just try running that module's tests alone, with ./phobos2-test-runner std.stdio?

Yes, std.stdio not crashed if runs alone (release and debug versions).

[joakim-noah]

As @kinke said, this is a known ARM bug with an issue already open, #2024. Feel free to file an issue for your problems with your own code, if you can narrow something down to a reproducible code sample.