On 12/26/07, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
> Getting a stack trace should be easier.
> Especially considering there have been patches to phobos floating around
> for a year at least that already implement it.

I don't need a whole stack tracing mechanism. I only want to know which line of source code tried to dereference a null pointer. More than that is overkill.

Ideally, I'd want runtime checks for null dereference compiled into the code whenever -debug is present on the command line. Alternatively, if that's too general, why not invent a new compiler switch, say -nullcheck?

(And speaking of compiler switches, could we possibly allow them to start with /two/ minus signs instead of one, e.g. --dubug?)

Bill Baxter wrote:
> 
> If you're not on Windows then I presume gdb works?  I guess that doesn't have any D-specific knowledge.  Support for D in zerobugs is still vaporware?

I did a quick test, and zerobugs has at least some D support. Types seems to be correctly demangled in the variables view, whereas functions and method names in the stack trace are not. I wasn't immediately able to pinpoint the location of my segfault though (a real one that I knew of), although the stacktrace showed up. Definately better looking than gdb, all in all :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Robby schrieb:
 > 4.) SWT. Yeah, *that* SWT.

News on this?
I sent you an email.

Frank

Bill Baxter wrote:
> ddbg does a pretty decent job on Windows.  Still, it gives me no stack trace upon "access violation" a significant fraction of the time.  When it works it's great, though.  You should definitely be using it if you're on Windows.  I have also found that Windbg can sometimes get a stack trace when ddbg can't.
> 
> If you're not on Windows then I presume gdb works?  I guess that doesn't have any D-specific knowledge.  Support for D in zerobugs is still vaporware?
> 
> Still, I'm with you.  Getting a stack trace should be easier. Especially considering there have been patches to phobos floating around for a year at least that already implement it.
> 
> --bb

So, given traced exceptions, you trap the sigsegv with a function that throws an exception? And you'd put the stuff to catch the signal in a module constructor so you just have to import the segfault exception module.

I just did it in the past half hour; it's not much trouble. There's just a portability concern. But since DMD only works on Windows and Linux, that's less of a concern.

As a side note, Phobos doesn't seem to have anything related to signals, and Tango's translation of the header is quite brief, not including anything to trap signals.

And now I see a post about two years old with the same stuff, only better.

On Wed, 26 Dec 2007 10:33:40 +0100, Lars Ivar Igesund wrote:

> Bill Baxter wrote:
>> 
>> If you're not on Windows then I presume gdb works?  I guess that doesn't have any D-specific knowledge.  Support for D in zerobugs is still vaporware?
> 
> I did a quick test, and zerobugs has at least some D support. Types seems to be correctly demangled in the variables view, whereas functions and method names in the stack trace are not. I wasn't immediately able to pinpoint the location of my segfault though (a real one that I knew of), although the stacktrace showed up. Definately better looking than gdb, all in all :)


Yes, just recently I've been experimenting with zerobugs.  It was much easier to use with D than the other linux debuggers since D symbols are demangled. The stacktrace does kind of show the general position of the segfault also.  I like the way it opens any associated shared libraries and shows the disassembly in a new tab as you step into the function calls.

One frustration is that char[] still are represented as a length and pointer, thus you don't get to see the text object associated with it. But even then, sometimes you can see it by expanding the related tree for the ptr object.

-JJR

Bill Baxter Wrote:
> If you're not on Windows then I presume gdb works?  I guess that doesn't have any D-specific knowledge.  Support for D in zerobugs is still vaporware?

It looks like it's going that way.  Looking at the zerobugs FAQ, I see:

 Does Zero work with other languages than C/C++?
    A: I have not tested it with other languages. However, the debug information in STABS and DWARF is language-independent.
The only language-dependent part in Zero is the interpreter which can only evaluate C++ expressions.

I have started some preliminary work to support Walter Bright's D Programming Language, and a D demangler has been contributed by the D community. However, this work is in an experimental stage.

Bill Baxter wrote:
> ddbg does a pretty decent job on Windows.  Still, it gives me no stack trace upon "access violation" a significant fraction of the time.

a good chunk of which was caused by a bug introduced in 0.11 that is fixed now in 0.11.2.

>  When it works it's great, though.  You should definitely be using it if you're on Windows.  I have also found that Windbg can sometimes get a stack trace when ddbg can't.

always feel free to drop test-cases in my mailbox, if possible ;)

John Reimer wrote:
> On Wed, 26 Dec 2007 10:33:40 +0100, Lars Ivar Igesund wrote:
> 
>> Bill Baxter wrote:
>>> If you're not on Windows then I presume gdb works?  I guess that
>>> doesn't have any D-specific knowledge.  Support for D in zerobugs is
>>> still vaporware?
The debugger cannot help much when the debug information produced by the compiler is not 100% accurate.

>> I did a quick test, and zerobugs has at least some D support. Types
>> seems to be correctly demangled in the variables view, whereas functions
>> and method names in the stack trace are not. I wasn't immediately able
>> to pinpoint the location of my segfault though (a real one that I knew
>> of), although the stacktrace showed up. Definately better looking than
>> gdb, all in all :)
>  

An outline of how ZeroBUGS handles stack unwinding: if there is DWARF information present, then look for frame-unwinding information. Otherwise, assume the System V ABI for the i386 and PowerPC and Itanium ABI for X86_64.

Again, do not blame the debugger for what the compiler does not produce.

Unless you have a 100% accurate stack trace from another debugger for the same executable and platform, in which case I do beg you to send me a bug report.


> Yes, just recently I've been experimenting with zerobugs.  It was much easier to use with D than the other linux debuggers since D symbols are demangled. 

I use a very slightly modified version of Thomas Kuehne's demangler (basically I added a function to show his copyright when I display the About window, and tweaked the config.h). It is built as a shared object so  you are free to tinker with it, the code is here: http://www.zerobugs.org/demangle_d.tgz



> The stacktrace does kind of show the general position of the segfault also.  I like the way it opens any associated shared libraries and shows the disassembly in a new tab as you step into the function calls.
> 
> One frustration is that char[] still are represented as a length and pointer, thus you don't get to see the text object associated with it. But even then, sometimes you can see it by expanding the related tree for the ptr object.
> 
Do you have an associative array of chars, or just char[]? Associative arrays do not work yet (it is coming though, I promise), but char[] should work I just tried it today with dmd 2.0, see snapshot here: http://zero-bugs.com/zero-char.png

Best Regards and a Happy new Year();
 Cristian

Cristian Vlasceanu wrote:

> An outline of how ZeroBUGS handles stack unwinding: if there is DWARF information present, then look for frame-unwinding information. Otherwise, assume the System V ABI for the i386 and PowerPC and Itanium ABI for X86_64.
> 
> Again, do not blame the debugger for what the compiler does not produce.

I hope you have filed bugs in bugzilla about which information the compiler is not generating.

--bb

Bill Baxter wrote:
> Cristian Vlasceanu wrote:
> 
>> An outline of how ZeroBUGS handles stack unwinding: if there is DWARF information present, then look for frame-unwinding information. Otherwise, assume the System V ABI for the i386 and PowerPC and Itanium ABI for X86_64.
>>
>> Again, do not blame the debugger for what the compiler does not produce.
> 
> I hope you have filed bugs in bugzilla about which information the compiler is not generating.
> 
> --bb
> 
You mean issues like this one, for example:
http://d.puremagic.com/issues/show_bug.cgi?id=136

They never get addressed, so what's the point? I have limited resources so I am picking my fights.

But I hope that once Walter, Andrei and Company get their philosophical issues on const and unsigned settled, someone will have a weekend or two to spare on making the backend better.

Meanwhile I am enjoying my vacation in the Columbia Gorge ;)