stack tracing {was assert(condition[, message]) patch}

kris foo at bar.com
Thu Jun 1 10:42:08 PDT 2006


Oskar Linde wrote:
> pragma wrote:
>> Anyway, so I run some code that trips on an assert, and it coughs up
>> "foobar.d(42)" as where I need to look.  The assert has done its job, 
>> as I go to
>> line #42 and go hunting for the reason behind why it tripped up.  As I'm
>> basically flying blind (no watch window and no stack trace), my next 
>> step is
>> almost always: add a writefln() before the assert to get some more 
>> information
>> as to how this happened.  Meshing those two steps seems like an 
>> obvious choice
>> to me.
> 
> 
> What I do is redefine the implementation of assert to do:
> 
>  *(cast(int *)0) = 0;
> 
> That way, I get a segmentation fault and a core dump that the debugger 
> (gdb) is able to use to present me with a back trace and (all) local 
> variables available for inspection. This is immensely more useful than 
> letting assert throw an exception, which means losing all state and 
> stack trace information.
> 
> /Oskar


And therein lies the key: what everyone is asking for is a means to 
capture additional state with the assert()

Ideally, all code-testing would be performed within the comforting arms 
of a debugger. But it doesn't happen that way and, due to Murphy's law, 
the one and only time your code trips up is when it's not in the 
debugger. That's when you need additional state to help track things 
down; especially with those "non repeatable" bugs.

Having said that, a very large part of the valuable state is the 
stack-trace ~ "how did we get here" can be just as important as some key 
variable. Often more so. Thus, I tend to look at assert as the bare 
minimum of tools; scraping the barrel, if you will. That goes to show 
how poor the runtime diagnostic support really is in D at this time ~ 
we're actually better off with printf() than most anythng else :)

Thus when all is said and done, having support for a stack-trace seems 
far more valuable than the 'convenience' of an assert message. Although 
in the absence of the former, it's easy to see why assert() gets so much 
attention.

Finally, I suspect adding printf formatting to assert() would be binding 
complexity at a delicate level; partly because the formatting might try 
to allocate memory?

Let's get stack-tracing supported, instead of depending upon the 
marginally useful assert() statement :D

- Kris



More information about the Digitalmars-d mailing list