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

[James Dunne]

kris wrote:
> 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

I'm sorry but I really have to insert my skepticism here about stack traces.

Upon first glance it sounds like a wonderful idea, until you get to 
where Java is at.  Literally hundreds of lines of stack traces dumped 
into log files to wade thru, most of them completely useless because: 
THEY DON'T CONTAIN STATE!!!

Sure they have the call-stack state so you can see where the function 
calls came from but there are no local variables, no function parameter 
values, no class/struct dumps; basically nothing useful for anything 
more complex than the simplest case of a deterministic function call, 
and even then it's not too terribly useful.

While I agree that it is better than nothing, we can still do better. 
An entire run-time debugging framework is what we really want to shoot 
for.  Exception logging, tracing, dumping of object contents, reading 
local variables, reading function parameters, etc.  This probably 
requires the help of a compile-time reflection system (where certain 
properties of objects are translated by the compiler into literal 
expressions).  Run-time reflection isn't really necessary.

-- 
Regards,
James Dunne