Having a proper debugging support of D programs on linux/OSX/windows should be a top priority, as it makes bug fixing really hard.<br>I also spent some time with zerobugs route. It looks like a dead end and its developer will most likely not put more effort into it.<br>
<br>Here&#39;s what I have:<br><br>A) default stacktraces on linux (ubuntu, if that matters): (dmd -g test_hello.d which has an assert(0);){<br>no function name, no file, no line numbers: <br>core.exception.AssertError@tests.test_hello(6): Assertion failure<br>
----------------<br>filename() [0x40fc16]<br>filename() [0x40d86d]<br>...<br>}<br><br>B) default stacktraces on OSX{<br>function name, but no file and no line numbers<br>core.exception.AssertError@tests.test_hello(9): Assertion failure<br>
----------------<br>5   test                                0x000000010f6305a6 _d_assertm + 38<br>6   test                                0x000000010f61204a void tests.test_hello.__assert(int) + 26<br>7   test                                0x000000010f612016 _Dmain + 42<br>
8   test                                0x000000010f630e95 extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).void runMain() + 33<br>...<br>}<br><br>C) stacktraces on OSX with some modifications I did involving wrapping atos, etc: {<br>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">shows function name, full file, line numbers, and catches segfaults.<br> 0  file: exception.d:356 pure @safe bool std.exception.enforce!(bool).enforce(bool, lazy const(char)[], immutable(char)[], ulong)<br>
1  file: path/som_file.d:100 void util.some_function(int x)<br>...<br><br>Some problems:<br> in case of segfault, the very latest stack frame is missing (so we only have the parent of the parent of the function that caused the segfault, plus anything older).<br>
<br>in some rare cases we only have the file name but no file path information.</blockquote>}<br><br>D) debugging on ubuntu:<div>gdb/cgdb works ok: file, line numbers, we can break on a un-mangled function name.</div><div>
However it seems name demangling is partial: I see stuff like std.stdio.__T7writelnTAAyaZ.writeln() (_param_0=...); maybe it has issues with templates.  Also, I have issue making info locals work, and it doesn&#39;t understand full D syntax etc.</div>
<div><br></div><div>E) debugging on OSX with apple&#39;s gdb (apple ships an old gdb: 6.3.50):</div><div><div>shows full file path, line numbers, but no symbol demangling. Cannot break on unmangled function name.</div><div>
<br></div></div><div><div>F) debugging on OSX with 7.5.1 (eg: brew install <a href="https://raw.github.com/Homebrew/homebrew-dupes/master/gdb.rb){">https://raw.github.com/Homebrew/homebrew-dupes/master/gdb.rb){</a></div></div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>* requires to be run with sudo or code-signing</div></div><div>* doesn&#39;t show file/line numbers; function names appear mangled, eg: </div><div>#1  0x000000010000104a in D5tests10test_hello8__assertFiZv ()</div>
</blockquote><div><div>}</div><div><br></div><div></div></div><div><br></div><div><br></div><div>Conclusions:</div><div>stacktraces on OSX can be made to work almost perfectly (caveat: missing last stack frame on segfault), but doesn&#39;t work at all on linux</div>
<div>gdb works well on linux, but not at all on OSX</div><div><br></div><div>If anyone has a setup that works better at least in some respect, please let me know!</div>