September 01, 2017
> 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`).
September 02, 2017
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.
September 05, 2017
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.

September 05, 2017
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
September 05, 2017
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.
1 2
Next ›   Last »