www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - What's the proper way to debug D programs with GDB?

reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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
Mar 12 2010
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
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 :)
Mar 12 2010
next sibling parent reply grauzone <none example.net> writes:
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
Mar 12 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 17 2010
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
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
Mar 17 2010
parent reply Bernard Helyer <b.helyer gmail.com> writes:
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.
Mar 17 2010
parent reply grauzone <none example.net> writes:
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.
Mar 17 2010
parent reply Robert Clipsham <robert octarineparrot.com> writes:
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 :)
Mar 18 2010
parent reply Bernard Helyer <b.helyer gmail.com> writes:
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?
Mar 18 2010
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 18/03/10 23:22, Bernard Helyer wrote:

 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?


You can either upload it somewhere (eg http://omploader.org/ or some 
other file upload site if you've not got hosting), or email it to me (my 
address is the same as I use for the newsgroups). Either way if you 
tar/zip it up you should be able to save a few megs on that :)
Mar 18 2010
next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
On 19/03/10 12:32, Robert Clipsham wrote:

 On 18/03/10 23:22, Bernard Helyer wrote:

 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?


 You can either upload it somewhere (eg http://omploader.org/ or some
 other file upload site if you've not got hosting), or email it to me (my
 address is the same as I use for the newsgroups). Either way if you
 tar/zip it up you should be able to save a few megs on that :)


http://omploader.org/iM3ZudA

There you go. D2, run build.debug.sh to build. Modify the script to add 
options and the like. Built with `-gc` list _Dmain or break _Dmain 
doesn't work, if you force a segfault (remove the comments from the 
first few lines of ator.main and compile with -noboundscheck to cause 
one) bt doesn't work, etc, etc.
Mar 18 2010
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 19/03/10 00:34, Bernard Helyer wrote:

 http://omploader.org/iM3ZudA

 There you go. D2, run build.debug.sh to build. Modify the script to add
 options and the like. Built with `-gc` list _Dmain or break _Dmain
 doesn't work, if you force a segfault (remove the comments from the
 first few lines of ator.main and compile with -noboundscheck to cause
 one) bt doesn't work, etc, etc.


Thanks! I've managed to work this down to a 2 line test case:
----
void function() myfunc;
void main(){}
----
Which errors with:
----
Die: DW_TAG_padding (abbrev = 0, offset = 0)
         has children: FALSE
         attributes:
Dwarf Error: Cannot find type of die [in module /tmp/test]
----

Compile with either dmd -gc test.d or dmd -g test.d. I'll spend some 
more time with it now and see if I can figure out a cause so we can give 
a more useful bug report, if not I'll open a bug as is. If anyone else 
is getting different errors from gdb when using -gc, let me know and I 
can narrow them down too.
Mar 19 2010
parent reply grauzone <none example.net> writes:
Robert Clipsham wrote:

 On 19/03/10 00:34, Bernard Helyer wrote:

 http://omploader.org/iM3ZudA

 There you go. D2, run build.debug.sh to build. Modify the script to add
 options and the like. Built with `-gc` list _Dmain or break _Dmain
 doesn't work, if you force a segfault (remove the comments from the
 first few lines of ator.main and compile with -noboundscheck to cause
 one) bt doesn't work, etc, etc.


 
 Thanks! I've managed to work this down to a 2 line test case:
 ----
 void function() myfunc;
 void main(){}
 ----


Wow, good work...


 Which errors with:
 ----
 Die: DW_TAG_padding (abbrev = 0, offset = 0)
         has children: FALSE
         attributes:
 Dwarf Error: Cannot find type of die [in module /tmp/test]
 ----
 
 Compile with either dmd -gc test.d or dmd -g test.d. I'll spend some 
 more time with it now and see if I can figure out a cause so we can give 
 a more useful bug report, if not I'll open a bug as is. If anyone else 
 is getting different errors from gdb when using -gc, let me know and I 
 can narrow them down too.


If I compile it with dmd -gc test.d, start gdb (version "7.0.1-debian"), 
and type "break _Dmain", I just get "Dwarf Error: Cannot find DIE at 0x0 
referenced from DIE at 0x46 [in module /tmp/test]".

This is with dmd v1.055 without gdb patches (but some other custom 
patches, though I think none should affect the debugging infos).
Mar 19 2010
parent Robert Clipsham <robert octarineparrot.com> writes:
On 19/03/10 21:37, grauzone wrote:

 Wow, good work...


Thanks :) Took a while, but I got there.


 If I compile it with dmd -gc test.d, start gdb (version "7.0.1-debian"),
 and type "break _Dmain", I just get "Dwarf Error: Cannot find DIE at 0x0
 referenced from DIE at 0x46 [in module /tmp/test]".

 This is with dmd v1.055 without gdb patches (but some other custom
 patches, though I think none should affect the debugging infos).


I'm using dmd v2.040 with the gdb patches (gdb 6.8), which could explain 
the difference in error messages. I might have to give it a shot, as 
that error message looks far more useful than what I'm getting out of 
6.8. I'll keep playing for a bit, and if I don't start getting somewhere 
I'll try it :)
Mar 19 2010
prev sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 19/03/10 00:34, Bernard Helyer wrote:

 http://omploader.org/iM3ZudA

 There you go. D2, run build.debug.sh to build. Modify the script to add
 options and the like. Built with `-gc` list _Dmain or break _Dmain
 doesn't work, if you force a segfault (remove the comments from the
 first few lines of ator.main and compile with -noboundscheck to cause
 one) bt doesn't work, etc, etc.


http://d.puremagic.com/issues/show_bug.cgi?id=3987

Submitted to bugzilla with a test case, I couldn't narrow down the exact 
reason for it happening though, so that will have to be left to someone 
else. I'm pretty sure there's another bug in there somewhere too, 
because I came up with some odd errors while narrowing down a test 
case... I'll leave it until that is fixed though in case it's the same 
bug, unless someone can come up with another test case for me to work down.
Mar 19 2010
prev sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
On 19/03/10 12:32, Robert Clipsham wrote:

 On 18/03/10 23:22, Bernard Helyer wrote:

 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?


 You can either upload it somewhere (eg http://omploader.org/ or some
 other file upload site if you've not got hosting), or email it to me (my
 address is the same as I use for the newsgroups). Either way if you
 tar/zip it up you should be able to save a few megs on that :)


Found another, no function pointers in this one, I think. It's much 
smaller, too! D2, dmd -ofnetmon.bin netmon/*.d -gc -debug. Linux only.

http://omploader.org/iM3h0cw
Mar 24 2010
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 25/03/10 00:03, Bernard Helyer wrote:

 On 19/03/10 12:32, Robert Clipsham wrote:

 On 18/03/10 23:22, Bernard Helyer wrote:

 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?


 You can either upload it somewhere (eg http://omploader.org/ or some
 other file upload site if you've not got hosting), or email it to me (my
 address is the same as I use for the newsgroups). Either way if you
 tar/zip it up you should be able to save a few megs on that :)


 Found another, no function pointers in this one, I think. It's much
 smaller, too! D2, dmd -ofnetmon.bin netmon/*.d -gc -debug. Linux only.

 http://omploader.org/iM3h0cw


Excellent :) OmpLoader seems to be down right now, so I'll try again 
later... As soon as I can get it I'll see what I can do. In the mean 
time you could upload it somewhere else or email it to me directly (I'll 
post here once I've got it :)).
Mar 25 2010
parent Bernard Helyer <b.helyer gmail.com> writes:
On 26/03/10 04:30, Robert Clipsham wrote:

 On 25/03/10 00:03, Bernard Helyer wrote:

 On 19/03/10 12:32, Robert Clipsham wrote:

 On 18/03/10 23:22, Bernard Helyer wrote:

 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?


 You can either upload it somewhere (eg http://omploader.org/ or some
 other file upload site if you've not got hosting), or email it to me (my
 address is the same as I use for the newsgroups). Either way if you
 tar/zip it up you should be able to save a few megs on that :)


 Found another, no function pointers in this one, I think. It's much
 smaller, too! D2, dmd -ofnetmon.bin netmon/*.d -gc -debug. Linux only.

 http://omploader.org/iM3h0cw


 Excellent :) OmpLoader seems to be down right now, so I'll try again
 later... As soon as I can get it I'll see what I can do. In the mean
 time you could upload it somewhere else or email it to me directly (I'll
 post here once I've got it :)).


Okay, I sent it to you. You should receive it with any luck.
Mar 25 2010
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 25/03/10 00:03, Bernard Helyer wrote:

 Found another, no function pointers in this one, I think. It's much
 smaller, too! D2, dmd -ofnetmon.bin netmon/*.d -gc -debug. Linux only.

 http://omploader.org/iM3h0cw


I think it's the same bug. A test case:
----
import std.stdio;
void main()
{
	writeln("");
}
----
I haven't narrowed it down further, because it requires most of phobos, 
and does include function pointers. I could attempt to narrow it down 
further, but I believe it has the same cause.
Mar 25 2010
parent reply Bernard Helyer <b.helyer gmail.com> writes:
On 26/03/10 12:13, Robert Clipsham wrote:

 ----
 I haven't narrowed it down further, because it requires most of phobos,
 and does include function pointers. I could attempt to narrow it down
 further, but I believe it has the same cause.


So the only way debugging will work is if we don't use Phobos? >_<;;

Thanks for your good work.
Mar 25 2010
parent Robert Clipsham <robert octarineparrot.com> writes:
On 25/03/10 23:29, Bernard Helyer wrote:

 So the only way debugging will work is if we don't use Phobos? >_<;;

 Thanks for your good work.


Seems so, at least until 
http://d.puremagic.com/issues/show_bug.cgi?id=3987 is fixed. 
Unfortunately I don't know enough about DWARF to chase this any further, 
at least without significant effort on my part, we we'll just have to 
sit tight, and hope Walter take a look at it :)
Mar 25 2010
prev sibling parent Robert Clipsham <robert octarineparrot.com> writes:
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.


Done. I've attached a patch to 
http://d.puremagic.com/issues/show_bug.cgi?id=3987 which seems to fix 
the issue. The problem was incorrect debug information being created for 
function pointers, it seems there shouldn't be a type for both the 
function and the pointer to it.
Mar 29 2010
prev sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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
Mar 12 2010
prev sibling parent Robert Clipsham <robert octarineparrot.com> writes:
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?


I've spent a lot of time on this, and with the patch from bug #3987 
applied debugging info should work, providing binaries are compiled with 
-gc and not -g :)
Apr 01 2010