www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - _Unwind_RaiseException

reply Oleg B <code.viator gmail.com> writes:
Hello. I work on project, that works on ARMv7 (Raspberry PI 2). 
Some times I get error in random places (build to build in 
different place, no rebuild - stable error place):

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

I found few issues on github

https://github.com/ldc-developers/ldc/issues/2208
https://github.com/ldc-developers/ldc/issues/2058
https://github.com/ldc-developers/ldc/issues/2024

But I don't understand how workaround this.
My ldc2.conf have no special flags, I don't use optimization.

default:
{
     switches = [
         "-I/usr/include/d/ldc",
         "-I/usr/include/d",
         "-mtriple=arm-linux-gnueabihf",
         "-gcc=arm-linux-gnueabihf-gcc",
         "-L-L/home/deviator/workspace/arm-linux-gnueabihf",
         "-defaultlib=phobos2-ldc,druntime-ldc",
         "-debuglib=phobos2-ldc-debug,druntime-ldc-debug"
     ];
};

Trying add "-mattr=+strict-align" has no effect.
I see only one way for fix it: don't use exceptions. But it 
require a lot of work on rewriting existing code. May be this 
problem has more elegant solution?
Sep 01
next sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 1 September 2017 at 10:04:51 UTC, Oleg B wrote:
 Hello. I work on project, that works on ARMv7 (Raspberry PI 2). 
 Some times I get error in random places (build to build in 
 different place, no rebuild - stable error place):

 [...]
What's the output of `ldc2 --version` ?
Sep 01
parent reply Oleg B <code.viator gmail.com> writes:
On Friday, 1 September 2017 at 10:14:54 UTC, Petar Kirov 
[ZombineDev] wrote:
 What's the output of `ldc2 --version` ?
LDC - the LLVM D compiler (1.3.0): based on DMD v2.073.2 and LLVM 4.0.0 built with LDC - the LLVM D compiler (1.3.0) Default target: x86_64-unknown-linux-gnu Host CPU: skylake last ldc from fedora repo
Sep 01
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 1 September 2017 at 10:19:07 UTC, Oleg B wrote:
 On Friday, 1 September 2017 at 10:14:54 UTC, Petar Kirov 
 [ZombineDev] wrote:
 What's the output of `ldc2 --version` ?
LDC - the LLVM D compiler (1.3.0): based on DMD v2.073.2 and LLVM 4.0.0 built with LDC - the LLVM D compiler (1.3.0) Default target: x86_64-unknown-linux-gnu Host CPU: skylake last ldc from fedora repo
Can you try https://github.com/ldc-developers/ldc/releases/tag/v1.4.0-beta1 ? Cross-compilation should be easier if you use the newly added ldc-build-runtime tool. There's a wiki page describing how it can be used: https://wiki.dlang.org/Building_LDC_runtime_libraries
Sep 01
parent Oleg B <code.viator gmail.com> writes:
On Friday, 1 September 2017 at 10:44:59 UTC, Petar Kirov 
[ZombineDev] wrote:
 Can you try 
 https://github.com/ldc-developers/ldc/releases/tag/v1.4.0-beta1 
 ?

 Cross-compilation should be easier if you use the newly added 
 ldc-build-runtime tool. There's a wiki page describing how it 
 can be used: 
 https://wiki.dlang.org/Building_LDC_runtime_libraries
Yes, I try it now, but this error is difficult to catch and, I think, if issues don't closed and in change log no information about this error it can occur again.
Sep 01
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 1 September 2017 at 10:04:51 UTC, Oleg B wrote:
 Hello. I work on project, that works on ARMv7 (Raspberry PI 2). 
 Some times I get error in random places (build to build in 
 different place, no rebuild - stable error place):

 [...]
It sounds like you have some memory corruption somewhere, doubt the issue is in exceptions. Can you try running the stdlib tests and see if those all pass? Easiest would be 1.4 beta with instructions Petar linked you to.
Sep 01
next sibling parent Oleg B <code.viator gmail.com> writes:
On Friday, 1 September 2017 at 15:36:55 UTC, Joakim wrote:
 Can you try running the stdlib tests and see if those all pass?
 Easiest would be 1.4 beta with instructions Petar linked you to.
How I can do this with minimal work?) I need to compile libs with -unittest flag and run empty file (void main(){}) on RPI?
Sep 01
prev sibling parent reply Oleg B <code.viator gmail.com> writes:
On Friday, 1 September 2017 at 15:36:55 UTC, Joakim wrote:
 Can you try running the stdlib tests and see if those all pass?
I build phobos and druntime with -unittest flag and run on RPI `void main(){}` and have this ./test Not safe to migrate Fibers between Threads on your system. Consider setting version CheckFiberMigration for this system in thread.d No more messages. I think all tests passed?
Sep 01
parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 1 September 2017 at 18:14:58 UTC, Oleg B wrote:
 On Friday, 1 September 2017 at 15:36:55 UTC, Joakim wrote:
 Can you try running the stdlib tests and see if those all pass?
I build phobos and druntime with -unittest flag and run on RPI `void main(){}` and have this ./test Not safe to migrate Fibers between Threads on your system. Consider setting version CheckFiberMigration for this system in thread.d No more messages. I think all tests passed?
Looks like at least core.thread ran, better to use the test runner to make sure. Just follow the instructions from that wiki page, there's even an example for Android. Simply replace with your toolchain and flags. You don't even need to build ldc, can use the ldc 1.4 beta release.
Sep 01
parent reply Oleg B <code.viator gmail.com> writes:
On Friday, 1 September 2017 at 19:28:51 UTC, Joakim wrote:
 You don't even need to build ldc, can use the ldc 1.4 beta 
 release.
I know, I build phobos and druntime on host x86. Run test on RPI.
Sep 01
next sibling parent kinke <noone nowhere.com> writes:
 I know, I build phobos and druntime on host x86. Run test on 
 RPI.
You seem to have missed the ldc-build-runtime `--testrunners` switch. You may also try using a more precise `-mtriple=armv7-linux-gnueabihf` and a specific CPU (`-mcpu=cortex-a8`).
Sep 01
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 1 September 2017 at 19:53:07 UTC, Oleg B wrote:
 On Friday, 1 September 2017 at 19:28:51 UTC, Joakim wrote:
 You don't even need to build ldc, can use the ldc 1.4 beta 
 release.
I know, I build phobos and druntime on host x86. Run test on RPI.
What I'm saying is that you can't be sure all the tests ran with the way you did it. Whereas if you use ldc-build-runtime with the --testrunners flag, the resulting test runner binaries- both the debug, unoptimized version and the optimized versions should be run, {druntime,phobos2}-test-runner[-debug] - will list every module that was tested. If all the tests run fine for you and you cannot reproduce, it suggests you might simply have a memory corruption in your own D code somewhere, as it's unlikely that running all the stdlib tests wouldn't reproduce such a bug.
Sep 02
next sibling parent reply Oleg B <code.viator gmail.com> writes:
On Saturday, 2 September 2017 at 10:21:02 UTC, Joakim wrote:
 If all the tests run fine for you and you cannot reproduce, it 
 suggests you might simply have a memory corruption in your own 
 D code somewhere, as it's unlikely that running all the stdlib 
 tests wouldn't reproduce such a bug.
druntime-test-runner[-debug] all passed phobos2-test-runner fails ****** FAIL release32 std.random core.exception.AssertError std/random.d(3092): Assertion failure ---------------- ./phobos2-test-runner(_D4core7runtime18runModuleUnitTestsUZ19unittestSegvHandlerUNbiPS4core3sys5posix6signal9siginfo_tPvZv+0x28)[0x43c5e6c] /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0x0)[0x76d2f6c0] ./phobos2-test-runner(_D11test_runner6doTestFPS6object10ModuleInfoKbZv+0x14c)[0x2df42ac] ./phobos2-test-runner(_D11test_runner6doTestFPS6object10ModuleInfoKbZv+0x14c)[0x2df42ac] ... ./phobos2-test-runner(_D11test_runner6doTestFPS6object10ModuleInfoKbZv+0x14c)[0x2df42ac] Segmentation fault phobos2-test-runner-debug has many fails 6.383s PASS release32 std.socket ./phobos2-test-runner-debug(_D4core7runtime18runModuleUnitTestsUZ19unittestSegvHandlerUNbiPS4core3sys5posix6signal9siginfo_tPvZv+0x5c)[0x4a0e6dc] /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0x0)[0x76cc56c0] /lib/arm-linux-gnueabihf/libpthread.so.0(pthread_join+0x10)[0x76e36358] ./phobos2-test-runner-debug(_D4core6thread6Thread4joinMFbZC6object9Throwable+0x2c)[0x4a15ff8] ./phobos2-test-runner-debug(_D3std11parallelism18_sharedStaticDtor9FZ14__foreachbody1MFKC4core6thread6ThreadZi+0x88)[0x3f549a8] ./phobos2-test-runner-debug(_D4core6thread6Thread7opApplyFMDFKC4core6thread6ThreadZiZi+0x7c)[0x4a16db4] ... debug(_D4core6thread6Thread7opApplyFMDFKC4core6thread6ThreadZiZi+0x7c)[0x4a16db4] ****** FAIL release32 std.stdio core.exception.AssertError std/stdio.d(1453): Fork crashed ---------------- exception.d:455 onAssertErrorMsg [0x4a03ab7] exception.d:632 _d_assert_msg [0x4a040d3] stdio.d:1453 void std.stdio.File.__unittestL1431_12().runForked(void delegate()) [0x44f6f3f] stdio.d:1459 void std.stdio.File.__unittestL1431_12() [0x44f6cf3] ... stdio.d:1459 void std.stdio.File.__unittestL1431_12() [0x44f6cf3] 1.282s PASS release32 std.string 0.001s PASS release32 std.traits ... 0.017s PASS release32 core.sync.semaphore Not safe to migrate Fibers between Threads on your system. Consider setting version CheckFiberMigration for this system in thread.d ****** FAIL release32 core.thread core.thread.ThreadError core/thread.d(3117): Error creating thread ---------------- 0.216s PASS release32 core.time 0.005s PASS release32 object ... 0.000s PASS release32 gc.config 1.170s PASS release32 gc.impl.conservative.gc 0.000s PASS release32 gc.bits And it's not finish and has no output over 30 minutes.
Sep 05
parent Joakim <dlang joakim.fea.st> writes:
On Tuesday, 5 September 2017 at 12:03:45 UTC, Oleg B wrote:
 On Saturday, 2 September 2017 at 10:21:02 UTC, Joakim wrote:
 If all the tests run fine for you and you cannot reproduce, it 
 suggests you might simply have a memory corruption in your own 
 D code somewhere, as it's unlikely that running all the stdlib 
 tests wouldn't reproduce such a bug.
druntime-test-runner[-debug] all passed phobos2-test-runner fails ****** FAIL release32 std.random core.exception.AssertError std/random.d(3092): Assertion failure ---------------- ./phobos2-test-runner(_D4core7runtime18runModuleUnitTestsUZ19unittestSegvHandlerUNbiPS4core3sys5posix6signal9siginfo_tPvZv+0x28)[0x43c5e6c] /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0x0)[0x76d2f6c0] ./phobos2-test-runner(_D11test_runner6doTestFPS6object10ModuleInfoKbZv+0x14c)[0x2df42ac] ./phobos2-test-runner(_D11test_runner6doTestFPS6object10ModuleInfoKbZv+0x14c)[0x2df42ac] ... ./phobos2-test-runner(_D11test_runner6doTestFPS6object10ModuleInfoKbZv+0x14c)[0x2df42ac] Segmentation fault
Try building this test runner again, after commenting out this one assert in std.random, a known bug on ARM: https://github.com/ldc-developers/phobos/blob/d548e8830aee86c024faf3279dd8d7e35d26aae8/std/random.d#L3318
 phobos2-test-runner-debug has many fails

 6.383s PASS release32 std.socket
 ./phobos2-test-runner-debug(_D4core7runtime18runModuleUnitTestsUZ19unittestSegvHandlerUNbiPS4core3sys5posix6signal9siginfo_tPvZv+0x5c)[0x4a0e6dc]
 /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0x0)[0x76cc56c0]
 /lib/arm-linux-gnueabihf/libpthread.so.0(pthread_join+0x10)[0x76e36358]
 ./phobos2-test-runner-debug(_D4core6thread6Thread4joinMFbZC6object9Throwable+0x2c)[0x4a15ff8]
 ./phobos2-test-runner-debug(_D3std11parallelism18_sharedStaticDtor9FZ14__foreachbody1MFKC4core6thread6ThreadZi+0x88)[0x3f549a8]
 ./phobos2-test-runner-debug(_D4core6thread6Thread7opApplyFMDFKC4core6thread6ThreadZiZi+0x7c)[0x4a16db4]
 ...
 debug(_D4core6thread6Thread7opApplyFMDFKC4core6thread6ThreadZiZi+0x7c)[0x4a16db4]
 ****** FAIL release32 std.stdio
 core.exception.AssertError std/stdio.d(1453): Fork crashed
 ----------------
 exception.d:455 onAssertErrorMsg [0x4a03ab7]
 exception.d:632 _d_assert_msg [0x4a040d3]
 stdio.d:1453 void 
 std.stdio.File.__unittestL1431_12().runForked(void delegate()) 
 [0x44f6f3f]
 stdio.d:1459 void std.stdio.File.__unittestL1431_12() 
 [0x44f6cf3]
 ...
 stdio.d:1459 void std.stdio.File.__unittestL1431_12() 
 [0x44f6cf3]
 1.282s PASS release32 std.string
 0.001s PASS release32 std.traits
 ...
 0.017s PASS release32 core.sync.semaphore
 Not safe to migrate Fibers between Threads on your system. 
 Consider setting version CheckFiberMigration for this system in 
 thread.d
 ****** FAIL release32 core.thread
 core.thread.ThreadError core/thread.d(3117): Error creating 
 thread
 ----------------
 0.216s PASS release32 core.time
 0.005s PASS release32 object
 ...
 0.000s PASS release32 gc.config
 1.170s PASS release32 gc.impl.conservative.gc
 0.000s PASS release32 gc.bits

 And it's not finish and has no output over 30 minutes.
Hmm, so only std.stdio and core.thread fail in the debug phobos tests? That's not many. As for the core.thread failure and the process not returning after the last test of the phobos test runner has run, that's reproducible for me on linux/x64 too, so not specific to linux/armhf. Test runs are looking pretty good, only one unknown bug, the std.stdio failure. This suggests a memory leak in your own code. Can you try building your code that's causing problems on linux/x64 with dmd and ldc and running it there too to see if you get those segfaults? That'll narrow it down to whether it's specific to ARM or not.
Sep 05
prev sibling parent Oleg B <code.viator gmail.com> writes:
On Saturday, 2 September 2017 at 10:21:02 UTC, Joakim wrote:
 If all the tests run fine for you and you cannot reproduce, it 
 suggests you might simply have a memory corruption in your own 
 D code somewhere, as it's unlikely that running all the stdlib 
 tests wouldn't reproduce such a bug.
I run phobos2-test-runner-debug in gdb and stop after gc.bits. #0 0x76e1d85c in sched_yield () at ../sysdeps/unix/syscall-template.S:84 #1 0x04a16b00 in core.thread.Thread.yield() () at thread.d:1177 #2 0x04a18a08 in thread_joinAll () at thread.d:2300 #3 0x04ad2af4 in rt_term () at dmain2.d:211 #4 0x04ad3218 in rt.dmain2._d_run_main(int, char**, extern(C) int(char[][]) function).runAll() () at dmain2.d:482 #5 0x04ad3120 in rt.dmain2._d_run_main(int, char**, extern(C) int(char[][]) function).tryExec(scope void() delegate) (dg=...) at dmain2.d:453 #6 0x04ad3020 in _d_run_main (argc=1, argv=0x7efff2a4, mainFunc=0x2f347a8 <D main>) at dmain2.d:486 #7 0x02f3492c in main (argc=1, argv=0x7efff2a4) at __entrypoint.d:8 #8 0x76d7c678 in __libc_start_main (main=0x7efff2a4, argc=1995051008, argv=0x76d7c678 <__libc_start_main+276>, init=<optimized out>, fini=0x4b1413c <__libc_csu_fini>, rtld_fini=0x76fdf9b8 <_dl_fini>, stack_end=0x7efff2a4) at libc-start.c:291 #9 0x02f33eac in _start () at ../sysdeps/arm/start.S:124
Sep 05