Jump to page: 1 2 3
Thread overview
What's the proper way to debug D programs with GDB?
Mar 12, 2010
Vladimir Panteleev
Mar 12, 2010
Robert Clipsham
Mar 12, 2010
grauzone
Mar 17, 2010
Walter Bright
Mar 18, 2010
Robert Clipsham
Mar 18, 2010
Bernard Helyer
Mar 18, 2010
grauzone
Mar 18, 2010
Robert Clipsham
Mar 18, 2010
Bernard Helyer
Mar 18, 2010
Robert Clipsham
Mar 19, 2010
Bernard Helyer
Mar 19, 2010
Robert Clipsham
Mar 19, 2010
grauzone
Mar 19, 2010
Robert Clipsham
Mar 19, 2010
Robert Clipsham
Mar 25, 2010
Bernard Helyer
Mar 25, 2010
Robert Clipsham
Mar 25, 2010
Bernard Helyer
Mar 25, 2010
Robert Clipsham
Mar 25, 2010
Bernard Helyer
Mar 25, 2010
Robert Clipsham
Mar 29, 2010
Robert Clipsham
Mar 12, 2010
Vladimir Panteleev
Apr 01, 2010
Robert Clipsham
March 12, 2010
Hi all,

I'm trying to debug some random crashes of some D services running on a Linux headless server.
I have compiled/linked my programs and Phobos with -g and without -O (using DMD), and applied the gdb patches from http://dsource.org/projects/gdb-patches/ .
I'm running a script based on https://wiki.ubuntu.com/Backtrace#Summary%20in%20script%20form to automatically record the backtrace and restart the program.
However, gdb still doesn't print very nice backtraces. Here's an example output:


[Thread debugging using libthread_db enabled]
[New Thread 0xf75506d0 (LWP 29591)]
Die: DW_TAG_<unknown> (abbrev = 9, offset = 449149)
        has children: FALSE
        attributes:
                DW_AT_byte_size (DW_FORM_data1) constant: 8
                DW_AT_type (DW_FORM_ref4) constant ref: 449143 (adjusted)
Dwarf Error: Cannot find type of die [in module /home/wnbot/wahostbot/HostingBuddy]
#0  0x080a72aa in _aaIn (aa={a = 0xf7461410}, keyti=0x8136969) at internal/aaA.d:253
        pkey = (void *) 0xff9439d8
        len = 97
        key_hash = 145249
        i = 40
        e = (struct aaA.aaA *) 0x180002
        c = 50Die: DW_TAG_<unknown> (abbrev = 4, offset = 52531)
        has children: FALSE
        attributes:
                DW_AT_byte_size (DW_FORM_data1) constant: 8
                DW_AT_type (DW_FORM_ref4) constant ref: 52523 (adjusted)

Dwarf Error: Cannot find type of die [in module /home/wnbot/wahostbot/HostingBuddy]


So, what's the proper way to set up D debugging on Linux? Should I just look into gdc?


-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
March 12, 2010
On 12/03/10 16:34, Vladimir Panteleev wrote:
> Hi all,
>
> I'm trying to debug some random crashes of some D services running on a
> Linux headless server.
> I have compiled/linked my programs and Phobos with -g and without -O
> (using DMD), and applied the gdb patches from
> http://dsource.org/projects/gdb-patches/ .
> I'm running a script based on
> https://wiki.ubuntu.com/Backtrace#Summary%20in%20script%20form to
> automatically record the backtrace and restart the program.
> However, gdb still doesn't print very nice backtraces. Here's an example
> output:
>
>
> [Thread debugging using libthread_db enabled]
> [New Thread 0xf75506d0 (LWP 29591)]
> Die: DW_TAG_<unknown> (abbrev = 9, offset = 449149)
> has children: FALSE
> attributes:
> DW_AT_byte_size (DW_FORM_data1) constant: 8
> DW_AT_type (DW_FORM_ref4) constant ref: 449143 (adjusted)
> Dwarf Error: Cannot find type of die [in module
> /home/wnbot/wahostbot/HostingBuddy]
> #0 0x080a72aa in _aaIn (aa={a = 0xf7461410}, keyti=0x8136969) at
> internal/aaA.d:253
> pkey = (void *) 0xff9439d8
> len = 97
> key_hash = 145249
> i = 40
> e = (struct aaA.aaA *) 0x180002
> c = 50Die: DW_TAG_<unknown> (abbrev = 4, offset = 52531)
> has children: FALSE
> attributes:
> DW_AT_byte_size (DW_FORM_data1) constant: 8
> DW_AT_type (DW_FORM_ref4) constant ref: 52523 (adjusted)
>
> Dwarf Error: Cannot find type of die [in module
> /home/wnbot/wahostbot/HostingBuddy]
>
>
> So, what's the proper way to set up D debugging on Linux? Should I just
> look into gdc?
>
>

It seems dmd is producing bad debug info here, you should report a bug if you can narrow it down to a test case which still does that. I've never had a problem using ldc with gdb and gdb-patches, so you could try that if you're using D1/Tango. Otherwise I don't know what to suggest, until the dmd bug is fixed... Other people have had similar problems, so if you manage to get a test case that you can put in bugzilla it might catch Walter's attention, getting gdb playing nicely with D seems to be important to him :)
March 12, 2010
Robert Clipsham wrote:
> On 12/03/10 16:34, Vladimir Panteleev wrote:
>> Hi all,
>>
>> I'm trying to debug some random crashes of some D services running on a
>> Linux headless server.
>> I have compiled/linked my programs and Phobos with -g and without -O
>> (using DMD), and applied the gdb patches from
>> http://dsource.org/projects/gdb-patches/ .
>> I'm running a script based on
>> https://wiki.ubuntu.com/Backtrace#Summary%20in%20script%20form to
>> automatically record the backtrace and restart the program.
>> However, gdb still doesn't print very nice backtraces. Here's an example
>> output:
>>
>>
>> [Thread debugging using libthread_db enabled]
>> [New Thread 0xf75506d0 (LWP 29591)]
>> Die: DW_TAG_<unknown> (abbrev = 9, offset = 449149)
>> has children: FALSE
>> attributes:
>> DW_AT_byte_size (DW_FORM_data1) constant: 8
>> DW_AT_type (DW_FORM_ref4) constant ref: 449143 (adjusted)
>> Dwarf Error: Cannot find type of die [in module
>> /home/wnbot/wahostbot/HostingBuddy]
>> #0 0x080a72aa in _aaIn (aa={a = 0xf7461410}, keyti=0x8136969) at
>> internal/aaA.d:253
>> pkey = (void *) 0xff9439d8
>> len = 97
>> key_hash = 145249
>> i = 40
>> e = (struct aaA.aaA *) 0x180002
>> c = 50Die: DW_TAG_<unknown> (abbrev = 4, offset = 52531)
>> has children: FALSE
>> attributes:
>> DW_AT_byte_size (DW_FORM_data1) constant: 8
>> DW_AT_type (DW_FORM_ref4) constant ref: 52523 (adjusted)
>>
>> Dwarf Error: Cannot find type of die [in module
>> /home/wnbot/wahostbot/HostingBuddy]
>>
>>
>> So, what's the proper way to set up D debugging on Linux? Should I just
>> look into gdc?
>>
>>
> 
> It seems dmd is producing bad debug info here, you should report a bug if you can narrow it down to a test case which still does that. I've never had a problem using ldc with gdb and gdb-patches, so you could try that if you're using D1/Tango. Otherwise I don't know what to suggest, until the dmd bug is fixed... Other people have had similar problems, so if you manage to get a test case that you can put in bugzilla it might catch Walter's attention, getting gdb playing nicely with D seems to be important to him :)

dmd producing buggy debugging information seems to be an old problem:
http://d.puremagic.com/issues/show_bug.cgi?id=1079
March 12, 2010
On Fri, 12 Mar 2010 18:53:05 +0200, Robert Clipsham <robert@octarineparrot.com> wrote:

> It seems dmd is producing bad debug info here, you should report a bug if you can narrow it down to a test case which still does that. I've never had a problem using ldc with gdb and gdb-patches, so you could try that if you're using D1/Tango. Otherwise I don't know what to suggest, until the dmd bug is fixed... Other people have had similar problems, so if you manage to get a test case that you can put in bugzilla it might catch Walter's attention, getting gdb playing nicely with D seems to be important to him :)

Thanks for the quick response! Unfortunately I'm still using D1/Phobos (*cough* get off my lawn... hehe). I'm going to give gdc a shot, though.

I could e-mail Walter a binary, but it doesn't look like it's necessary, according to grauzone's post.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
March 17, 2010
grauzone wrote:
> dmd producing buggy debugging information seems to be an old problem:
> http://d.puremagic.com/issues/show_bug.cgi?id=1079

The problem is that dmd produces dwarf debug info according to the dwarf spec. When gdb fails, I have no clue why, and nobody has ever been able to figure out just *what* in the dwarf info is causing gdb to fail.

Some problems were identified a few months back, and those were fixed (evidently gdb cannot handle module records, and gdb also relied on some undocumented stuff).

If anyone wants to peruse the gdb source and figure out exactly *what* it is choking on, that would be most appreciated.
March 18, 2010
On 17/03/10 22:50, Walter Bright wrote:
> grauzone wrote:
>> dmd producing buggy debugging information seems to be an old problem:
>> http://d.puremagic.com/issues/show_bug.cgi?id=1079
>
> The problem is that dmd produces dwarf debug info according to the dwarf
> spec. When gdb fails, I have no clue why, and nobody has ever been able
> to figure out just *what* in the dwarf info is causing gdb to fail.
>
> Some problems were identified a few months back, and those were fixed
> (evidently gdb cannot handle module records, and gdb also relied on some
> undocumented stuff).
>
> If anyone wants to peruse the gdb source and figure out exactly *what*
> it is choking on, that would be most appreciated.

I've spent about half an hour trying to track this down, and I can't seem to reproduce the problem. The only time I can get the errors mentioned here and in the listed bug is when using -g. When switching to -gc the problems disappear. Does anyone have a test case that fails with -gc too that I can play with?

The reason this happens when using -g is the D extensions to dwarf which GDB doesn't support (even with the gdb-patches applied) are used here, which causes the error, as gdb is unable to parse the debug info. When using -gc, dmd doesn't use the D extensions, so the error doesn't occur. To fix this, gdb would need patching to add support for the D extensions, or alternatively we'll have to keep using -gc.

----
void main()
{
        char[] foo;
        foo ~= 'a';
}
----
When compiled using -gc, gdb works as expected. When compiled with -g, gdb gives the following error:

(gdb) b test.d:3
Die: DW_TAG_<unknown> (abbrev = 4, offset = 77)
        has children: FALSE
        attributes:
                DW_AT_byte_size (DW_FORM_data1) constant: 8
                DW_AT_type (DW_FORM_ref4) constant ref: 69 (adjusted)
Dwarf Error: Cannot find type of die [in module /tmp/test]

Taking a look at the dwarf info for test:
% objdump --dwarf=abbrev test
-- SNIP --
   4      Unknown TAG value: 41    [no children]
    DW_AT_byte_size    DW_FORM_data1
    DW_AT_type         DW_FORM_ref4
-- SNIP --

Unknown TAG value at 41... This isn't part of the dwarf spec, looking at src/dmd/backend/dwarf2.h:
----
       // D programming language extensions
        DW_TAG_darray_type              = 0x41,
        DW_TAG_aarray_type              = 0x42,
        DW_TAG_delegate_type            = 0x43,

        DW_TAG_lo_user                  = 0x4080,
        DW_TAG_hi_user                  = 0xFFFF,
----

Oh look, 0x41 is a D extension, no wonder GDB chokes :)

I'll look more into this if someone can provide me a test case which doesn't require the D extensions to cause the error, currently this looks like a non-bug to me as gdb doesn't support D extensions yet (yes, this is even with a patched gdb).

Robert
March 18, 2010
On 18/03/10 13:04, Robert Clipsham wrote:
>
> I'll look more into this if someone can provide me a test case which
> doesn't require the D extensions to cause the error, currently this
> looks like a non-bug to me as gdb doesn't support D extensions yet (yes,
> this is even with a patched gdb).
>
> Robert

I have definitely had programs choke up gdb even when using the `-gc` flag. I'll have a poke around tonight and see what I can find.



-Bernard.
March 18, 2010
Bernard Helyer wrote:
> On 18/03/10 13:04, Robert Clipsham wrote:
>>
>> I'll look more into this if someone can provide me a test case which
>> doesn't require the D extensions to cause the error, currently this
>> looks like a non-bug to me as gdb doesn't support D extensions yet (yes,
>> this is even with a patched gdb).
>>
>> Robert
> 
> I have definitely had programs choke up gdb even when using the `-gc` flag. I'll have a poke around tonight and see what I can find.

Me too, but always in larger amounts of code, where it's hopeless to try to find the exact location. It's probably caused by a single obscure D feature...

> 
> -Bernard.
March 18, 2010
On 18/03/10 04:23, grauzone wrote:
> Bernard Helyer wrote:
>> I have definitely had programs choke up gdb even when using the `-gc`
>> flag. I'll have a poke around tonight and see what I can find.
>
> Me too, but always in larger amounts of code, where it's hopeless to try
> to find the exact location. It's probably caused by a single obscure D
> feature...

If either of you can manage to come up with a test case that fails with -gc, even if it's huge, let me know and I'll see if I can figure out what's happening :)


March 18, 2010
On 19/03/10 04:59, Robert Clipsham wrote:
> On 18/03/10 04:23, grauzone wrote:
>> Bernard Helyer wrote:
>>> I have definitely had programs choke up gdb even when using the `-gc`
>>> flag. I'll have a poke around tonight and see what I can find.
>>
>> Me too, but always in larger amounts of code, where it's hopeless to try
>> to find the exact location. It's probably caused by a single obscure D
>> feature...
>
> If either of you can manage to come up with a test case that fails with
> -gc, even if it's huge, let me know and I'll see if I can figure out
> what's happening :)
>
>

Okay got it. It's 6000 lines and six megabytes large (and hacked to all hell, as the std.string templates started breaking, for some reason), but it doesn't debug with `-gc`! What's the best way to get it to you?
« First   ‹ Prev
1 2 3