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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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.


../sysdeps/unix/syscall-template.S:84




int(char[][]) function).runAll() ()
     at dmain2.d:482

int(char[][]) function).tryExec(scope void() delegate) (dg=...) 
at dmain2.d:453

mainFunc=0x2f347a8 <D main>)
     at dmain2.d:486

__entrypoint.d:8

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
Sep 05 2017