Automatically print the segtrace for segfaulting tests

[wilzbach]

Useful because

• CIs: if a test segfaults on a CI --> we automatically get the stack trace
• local development: when something segfaults, you probably want to look at the stack trace

An alternative would be to use coredumpctl gdb -1, but that's systemd-only and I don't know whether all CIs support this.

So what do you think about this?

[dlang-bot]

Thanks for your pull request, @wilzbach!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#8132"

[jacob-carlborg]

Why only Linux?

[wilzbach]

Because I didn't know whether it would work on other platforms and I thought it's good to start with something that I can test. Also most of our CIs are Linux ones, so it would already have a measurable impact.
IIRC OSX uses lldb and Windows has who knows what debugger available?

(+I didn't feel like fighting the auto-tester for something that hasn't received feedback yet.)

[jacob-carlborg]

There's registerMemoryErrorHandler as well. But that is only implemented for Linux.

[wilzbach]

There's registerMemoryErrorHandler as well. But that is only implemented for Linux.

DMD is built in release mode on e.g. the auto-tester, so AFAICT unfortunately this won't work.
FYI: sth. similar has been tried before (see e.g. #6103), but this was blocked on the output of DIP1006 :/

[JinShil]

I suggest adding a simple comment here describing what this is for, so the next person to modify this code doesn't have to do so much investigation.

[JinShil]

I like it.

[wilzbach]

BTW here's how this will look like:

 ... compilable/foo.d                -fPIC ()
sh: line 1:  6086 Segmentation fault      (core dumped) ../generated/linux/release/64/dmd -conf= -m64 -Icompilable -fPIC -odtest_results/compilable -oftest_results/compilable/foo_0.o -c compilable/foo.d > test_results/fa6211c06986167f92e582fe24165c671874856a5ffc0bae595cf8f133ed6bf 2>&1
Test compilable/foo.d failed.  The logged output:
../generated/linux/release/64/dmd -conf= -m64 -Icompilable  -fPIC  -odtest_results/compilable -oftest_results/compilable/foo_0.o  -c compilable/foo.d 


==============================
Test compilable/foo.d failed: expected rc == 0, exited with rc == 139

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000055555589c9a7 in semanticTraits(TraitsExp*, Scope*) ()
#0  0x000055555589c9a7 in semanticTraits(TraitsExp*, Scope*) ()
#1  0x00005555558157cd in ExpressionSemanticVisitor::visit(TraitsExp*) ()
#2  0x000055555580527d in TraitsExp::accept(Visitor*) ()
#3  0x00005555558246e7 in expressionSemantic(Expression*, Scope*) ()
#4  0x000055555578c525 in _D3dmd4cond13StaticForeach7prepareMFPSQBk6dscope5ScopeZv ()
#5  0x0000555555785b5c in StaticForeachDeclaration::include(Scope*) ()
#6  0x00005555557d57e9 in _D3dmd7dsymbol12ScopeDsymbol8_foreachFPSQBm6dscope5ScopePSQCe4root5array__T5ArrayTCQDdQDc7DsymbolZQxMDFmQwZiPmZi ()
#7  0x000055555589eeb3 in semanticTraits(TraitsExp*, Scope*) ()
#8  0x00005555558157cd in ExpressionSemanticVisitor::visit(TraitsExp*) ()
#9  0x000055555580527d in TraitsExp::accept(Visitor*) ()
#10 0x00005555558246e7 in expressionSemantic(Expression*, Scope*) ()
#11 0x000055555578c525 in _D3dmd4cond13StaticForeach7prepareMFPSQBk6dscope5ScopeZv ()
#12 0x0000555555785b5c in StaticForeachDeclaration::include(Scope*) ()
...

Luckily there are enough ICEs available, this one was "tested" with https://issues.dlang.org/show_bug.cgi?id=18718

[JinShil]

So no longer an RFC?

[JinShil]

Also, if a stack trace is added to #8138 will this even be necessary?

I like the idea, I'm not convinced of the implementation yet. I though DMD had a way to output the stack trace without using GDB. Am I mistaken?

Ah, I'm confusing a program segfault with a compiler segfault.

[JinShil]

I would prefer if we didn't start using informal chatting abbreviations. Please spell out "so that".

[wilzbach]

FWIW wiktionary lists it as:

(mathematics) Abbreviation of "such that".

https://en.wiktionary.org/wiki/s.t.

but I don't mind changing it.

[nordlow]

How can I make use of this idea during local development of my dub projects in Linux?

[wilzbach]

Not sure what you are referring to?
You want dub to automatically start gdb?
Then just define a simple bash script that does so and pass it it to dub with --compiler?

[nordlow]

I want dub run to print the stacktrace of my app when it segfaults.