I've come across a problem that when -O is used, app which normally works end up with segfault.
It's this benchmark: https://github.com/kostya/benchmarks/blob/master/havlak/havlak.d
When compiled with: dmd -ofhavlak_d -O -release -inline havlak.d
It segfaults at least for me (it seams to work for repository author according to test results)
DMD64 D Compiler v2.067.0
Linux 3.19.3-gentoo #1 SMP Fri Mar 27 10:41:00 CET 2015 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux
GDC, LDC and DMD without -O are working ok.
I'm trying to dustmite the problem and I'll post the results.
Comment #1 by chalucha — 2015-04-26T18:48:06Z
Its really hard for me (as a D noob) to dustmite something usable from this :(
The output from gdb is:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7aa5407 in object.TypeInfo_Class.getHash(const(void*)) () from /opt/dmd-2.067/lib64/libphobos2.so.0.67
#0 0x00007ffff7aa5407 in object.TypeInfo_Class.getHash(const(void*)) () from /opt/dmd-2.067/lib64/libphobos2.so.0.67
#1 0x00007ffff7ac371a in _aaInX () from /opt/dmd-2.067/lib64/libphobos2.so.0.67
#2 0x00007ffff7ac36d0 in _aaGetRvalueX () from /opt/dmd-2.067/lib64/libphobos2.so.0.67
#3 0x0000000000407bf8 in test.HavlakLoopFinder.DSF(test.BasicBlock, test.UnionFindNode[], int[test.BasicBlock], int[], int) ()
#4 0x0000000000407c48 in test.HavlakLoopFinder.DSF(test.BasicBlock, test.UnionFindNode[], int[test.BasicBlock], int[], int) ()
#5 0x0000000000407c48 in test.HavlakLoopFinder.DSF(test.BasicBlock, test.UnionFindNode[], int[test.BasicBlock], int[], int) ()
It has deterministic behaviour, always segfaults on the 12th iteration.
I've made a PR https://github.com/kostya/benchmarks/pull/23
which ads final to classes to speed it up a bit and this problem no longer occur with these changes - I have no idea why
dustmite is problematic because it can lead to versions which segfaults too, but with other reason or which eats all mem, etc. And is slow as hell to test outputs from all variants (-O -release, -release, -debug) - I let it run for more than 24hours actually with just slightly shorter version..
So I tried manually compare version which works and version which don't and made an attachment with failing version and with simplified patch to working version.
Patch consists of 3 changes.
I would guess something with:
new BasicBlockEdge(... instead of just BasicBlockEdge(...
BasicBlockEdge is a struct
But don't understand internals of what new means for structs?
Comment #7 by dlang-bugzilla — 2015-04-27T21:28:30Z
(In reply to Tomáš Chaloupka from comment #6)
> dustmite is problematic because it can lead to versions which segfaults too,
> but with other reason or which eats all mem, etc. And is slow as hell to
> test outputs from all variants (-O -release, -release, -debug) - I let it
> run for more than 24hours actually with just slightly shorter version..
Um, did you read the linked page?
Your test script should do the following:
1. Compile the program without -O
2. Run the program and check that it exits successfully. You can use "timeout" and "ulimit" to limit how much time and memory the program can consume.
3. If the above program works fine, compile it again with -O
4. Run the program and checks that it crashes (or produces output different from the first run)
5. If the first run was OK and the second run crashed, return 0 (you have reproduced the bug). Otherwise, return 1
Comment #8 by chalucha — 2015-04-28T21:05:51Z
Actually read it before. Tried to use prepared script with specific backtrace, but could not make it work with timeout (wrong output from gdb then).
So now trying with just simple:
#!/bin/bash
TIME=12
timeout $TIME rdmd --force -O -release test.d 2>&1 > /dev/null
if [ $? -eq 139 ]; then
timeout $TIME rdmd --force -release test.d 2>&1 > /dev/null
if [ $? -eq 124 ]; then
timeout $TIME rdmd --force test.d 2>&1 > /dev/null
if [ $? -eq 124 ]; then
exit 0
else
exit 1
fi
else
exit 1
fi
fi
exit 1
which is at least faster thanks to timeout usage.
Comment #9 by chalucha — 2015-04-29T04:32:31Z
So it ended up with an indeterministic version which sometimes pass, sometimes fails in all switches :(
Is it actually failing for anyone else?
Comment #10 by robert.schadek — 2024-12-13T18:42:33Z