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

[Don Clugston]

James Dunne wrote:
> 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.


I have to disagree with this. A stack trace does give you the most 
important piece of state information: the value of function pointers and 
delegates that are called. Personally, I don't think I've ever learnt 
much from a debugger other than seeing the call stack; it gives a list 
of all the places to look at for bugs (and the places to put more 
asserts into!). It covers >90% of the use cases.