<br><br><div class="gmail_quote">On Fri, Apr 29, 2011 at 9:41 AM, Steve Schveighoffer <span dir="ltr"><<a href="mailto:schveiguy@yahoo.com">schveiguy@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div style="color:#000;background-color:#fff;font-family:arial, helvetica, sans-serif;font-size:12pt"><div><span>I'll mention that I just was debugging some stuff in Linux for dcollections, and the line numbers for the unit tests given by gdb were off by a couple of lines (I had the same feelings you are having, how is this possible).  That was just inside the unit tests.  In the actual code, the line numbers were correct.  What's more, when I would step over lines in gdb, the program would jump *back* some lines when there was no loop in the code.</span></div>
<div><br><span></span></div><div><span>I wouldn't trust that GDB is giving you accurate info.<br></span></div><div><br><span></span></div><div><span>My recommendation -- try using writeln debugging if possible.</span></div>
</div></div></blockquote><div><br>Thanks for the info.  The problem with writeln is that, when dealing with nondeterministic bugs-from-Hell, you don't want to change timings or have screens and screens of stuff printed.  Now that I think of it, though, scope(failure) might be useful here.  For example:<br>
<br>void fun() {<br>    scope(failure) stderr.writeln("Failed in fun().");<br>    // Do stuff.<br>}<br><br> Also, I'll try running the code in a main block instead of a unittest block.  If it works then it's a compiler bug w.r.t. unit tests.<br>
</div></div>