www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D 2.0 Stacktrace

reply Benjamin Thaut <code benjamin-thaut.de> writes:
I wrote a small piece of sourcecode that generates stacktraces in D 2.0 under
windows. It works both with the pdb and cv debug symbol format. For Exceptions
that are derived from the Error class the trace information is automatically
appended, this causes all builtin D errors to get a stacktrace information.
The only point where this does not work is the Access Vioaltion error, as it
does not call the stacktrace callback function for some reason.

It is very easy to use, just copy the two files from the zip archive to your
root source directory and import the stacktrace module inside your main file.
For more informaiton and the download go to:
http://3d.benjamin-thaut.de

Let me know what you think.

Kind Regards
Benjamin Thaut
Oct 06 2010
next sibling parent Stephan <spam extrawurst.org> writes:
Thanks that is pretty cool !


On 06.10.2010 13:50, Benjamin Thaut wrote:
 I wrote a small piece of sourcecode that generates stacktraces in D 2.0 under
 windows. It works both with the pdb and cv debug symbol format. For Exceptions
 that are derived from the Error class the trace information is automatically
 appended, this causes all builtin D errors to get a stacktrace information.
 The only point where this does not work is the Access Vioaltion error, as it
 does not call the stacktrace callback function for some reason.

 It is very easy to use, just copy the two files from the zip archive to your
 root source directory and import the stacktrace module inside your main file.
 For more informaiton and the download go to:
 http://3d.benjamin-thaut.de

 Let me know what you think.

 Kind Regards
 Benjamin Thaut

Oct 06 2010
prev sibling next sibling parent reply Stephan <spam extrawurst.org> writes:
I found a thread about the missing access violations:
http://www.digitalmars.com/d/archives/digitalmars/D/TraceHandler_not_being_called_on_Access_violation_112557.html#N112580

did you issue a bug report or was there any progress on this, i mean the 
thread is kinda old.

On 06.10.2010 13:50, Benjamin Thaut wrote:
 I wrote a small piece of sourcecode that generates stacktraces in D 2.0 under
 windows. It works both with the pdb and cv debug symbol format. For Exceptions
 that are derived from the Error class the trace information is automatically
 appended, this causes all builtin D errors to get a stacktrace information.
 The only point where this does not work is the Access Vioaltion error, as it
 does not call the stacktrace callback function for some reason.

 It is very easy to use, just copy the two files from the zip archive to your
 root source directory and import the stacktrace module inside your main file.
 For more informaiton and the download go to:
 http://3d.benjamin-thaut.de

 Let me know what you think.

 Kind Regards
 Benjamin Thaut

Oct 06 2010
parent Benjamin Thaut <code benjamin-thaut.de> writes:
That thread is from me. I did not issue a bug report yet, but I posted a
question
if there was any progress on this issue.

Kind Regards
Benjamin Thaut
Oct 06 2010
prev sibling next sibling parent reply "Yao G." <yao.gomez spam.gmail.com> writes:
Hi Benjamin.

I've tried your stacktrace code, with DMD v2.049, on Windows XP. But I hit  
two issues:

1. When compiling with -w (warnings) I get this error on your code:

 C:\dmd\src\stacktrace.d(218): Warning: overrides base class function  
 object.Object.toString, but is not marked with 'override'

Compiles either adding the override keyword, or without using the -w switch. 2. With this simple program: --- import stacktrace; void main( string[] args ) { throw new Exception("Test"); } --- I get the following in the command line:
 object.Exception: Test
 ----------------
 00 4683480
 01 4683543
 02 4683233
 03 4887305
 04 RegisterWaitForInputIdle

I just get a bunch of (I presume) addresses, but no names for the methods in the stack trace chain. I don't know if there something wrong with my setup, or maybe something is interfering with the stack trace printing. Any thoughts? -- Yao G.
Oct 06 2010
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
You have to compile with the -g option so that dmd produces debugging symbols.
Without symbols you will get just the addresses in your callstack. Didn't check
for warnings, will fix that.

Kind Regards
Benjamin Thaut
Oct 06 2010
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Exactly the same code and the same compiler options give the following results
for me:

object.Exception: Test
----------------
00 extern (C) int rt.dmain2.main(int, char**) . void runMain() .
01 extern (C) int rt.dmain2.main(int, char**) . void runAll() .
02 main
03 mainCRTStartup
04 BaseThreadInitThunk
05 RtlInitializeExceptionChain
06 RtlInitializeExceptionChain

Can you please check which version of dbghelp.dll is installed on your system?

Which exact version of XP do you use? (service pack, x86/x64)?

Kind Regards
Benjamin Thaut
Oct 06 2010
prev sibling parent reply Austin Hastings <ah08010-d yahoo.com> writes:
On 10/6/2010 4:00 PM, Yao G. wrote:
 I forgot to mention. I'm compiling the file using:

 dmd test.d C:\dmd\src\stacktrace.d C:\dmd\src\dbghelp.d -g -w


I have a similar problem as Yao. I've got XP SP3/x86 with dbghelp.dll version 5.1.2600.5512 in the windows\system32 directory. I copied dbghelp.dll version 6.12.2.633 from a recent install of Debugging Tools for Windows (x86) into the directory with the stacktrace sources. $ ls -alG total 1211 drwxr-xr-x 2 Austin 0 Oct 7 21:12 . drwxr-xr-x 3 Austin 0 Oct 7 20:11 .. -rw-r--r-- 1 Austin 9020 Oct 7 21:04 dbghelp.d -rwxr-xr-x 1 Austin 1213200 Oct 7 20:21 dbghelp.dll -rw-r--r-- 1 Austin 1331 Oct 7 20:11 licence.txt -rw-r--r-- 1 Austin 1277 Oct 7 20:11 readme.txt -rw-r--r-- 1 Austin 11335 Oct 7 20:11 stacktrace.d -rw-r--r-- 1 Austin 90 Oct 7 20:11 test.d I compile using: $ dmd -g -w test.d stacktrace.d dbghelp.d which succeeds no problem. I put code in to check the result of the loadLibrary call, and it reports: Got valid dll handle Path: d:\devel\d\libs\src\stacktrace\dbghelp.dll So the right version is being opened. But I still get: object.Exception: Test ---------------- 00 4223864 01 4223927 02 4223617 03 4439269 04 RegisterWaitForInputIdle I'm fairly certain I meet all the basic requirements: compile with -g for debug info, copy a late version of dbghelp.dll into application directory. But I'm getting the InputIdle failure, which acts like it doesn't matter. Is there an upper limit on the dbghelp.dll version? I notice that Yao reported using 6.7.5, while 6.12 is leading edge. What version are you using, Benjamin? Thanks in advance for any help, I'm really looking forward to using this module. =Austin
Oct 07 2010
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 08.10.2010 03:16, schrieb Austin Hastings:
 On 10/6/2010 4:00 PM, Yao G. wrote:
 I forgot to mention. I'm compiling the file using:

 dmd test.d C:\dmd\src\stacktrace.d C:\dmd\src\dbghelp.d -g -w


I have a similar problem as Yao. I've got XP SP3/x86 with dbghelp.dll version 5.1.2600.5512 in the windows\system32 directory. I copied dbghelp.dll version 6.12.2.633 from a recent install of Debugging Tools for Windows (x86) into the directory with the stacktrace sources. $ ls -alG total 1211 drwxr-xr-x 2 Austin 0 Oct 7 21:12 . drwxr-xr-x 3 Austin 0 Oct 7 20:11 .. -rw-r--r-- 1 Austin 9020 Oct 7 21:04 dbghelp.d -rwxr-xr-x 1 Austin 1213200 Oct 7 20:21 dbghelp.dll -rw-r--r-- 1 Austin 1331 Oct 7 20:11 licence.txt -rw-r--r-- 1 Austin 1277 Oct 7 20:11 readme.txt -rw-r--r-- 1 Austin 11335 Oct 7 20:11 stacktrace.d -rw-r--r-- 1 Austin 90 Oct 7 20:11 test.d I compile using: $ dmd -g -w test.d stacktrace.d dbghelp.d which succeeds no problem. I put code in to check the result of the loadLibrary call, and it reports: Got valid dll handle Path: d:\devel\d\libs\src\stacktrace\dbghelp.dll So the right version is being opened. But I still get: object.Exception: Test ---------------- 00 4223864 01 4223927 02 4223617 03 4439269 04 RegisterWaitForInputIdle I'm fairly certain I meet all the basic requirements: compile with -g for debug info, copy a late version of dbghelp.dll into application directory. But I'm getting the InputIdle failure, which acts like it doesn't matter. Is there an upper limit on the dbghelp.dll version? I notice that Yao reported using 6.7.5, while 6.12 is leading edge. What version are you using, Benjamin? Thanks in advance for any help, I'm really looking forward to using this module. =Austin

it seems to work. It just can not resolve symbols inside your application. There is no upper limit to dbghelp.dll. I'm on Windows 7 with dbghelp version 6.1.7600.16385. Most likely the probelm are the CV debugging symbols, as it was kind of hacky to get it to read those. Try converting your application with cv2pdb to pdb debugging symbols and see if this fixes the problem. -- Kind Regards Benjamin Thaut
Oct 07 2010
parent reply Austin Hastings <ah08010-d yahoo.com> writes:
On 10/8/2010 2:46 AM, Benjamin Thaut wrote:

 Hm I don't have a XP machine to test on. But as Symbol 04 is resolved,
 it seems to work. It just can not resolve symbols inside your
 application. There is no upper limit to dbghelp.dll. I'm on Windows 7
 with dbghelp version 6.1.7600.16385. Most likely the probelm are the CV
 debugging symbols, as it was kind of hacky to get it to read those. Try
 converting your application with cv2pdb to pdb debugging symbols and see
 if this fixes the problem.

I ran cv2pdb.exe on the binary, and that works a treat: object.Exception: Test ---------------- 00 rtdmain2mainrunMain 01 rtdmain2mainrunAll 02 main 03 mainCRTStartup 04 RegisterWaitForInputIdle Thanks for your help, Benjamin! My next question would be, why does the stack trace look this way? I'm throwing the exception from D's main. I assume that's entry #02. But what are the other two entries, and why are they on the stack? =Austin
Oct 08 2010
parent reply Austin Hastings <ah08010-d yahoo.com> writes:
On 10/8/2010 6:47 PM, Denis Koroskin wrote:
 On Sat, 09 Oct 2010 02:36:30 +0400, Austin Hastings <ah08010-d yahoo.com>
wrote:

 object.Exception: Test
 ----------------
 00 rtdmain2mainrunMain
 01 rtdmain2mainrunAll
 02 main
 03 mainCRTStartup
 04 RegisterWaitForInputIdle

 Thanks for your help, Benjamin!

 My next question would be, why does the stack trace look this way? I'm
 throwing the exception from D's main. I assume that's entry #02. But
 what are the other two entries, and why are they on the stack?


 D main is not the true program entry point, there is a lot of
 preparation done (gc_init(), module init, etc) before your main() takes
 control, and these entries can be safely stripped since they are usually
 not what you are looking for.

Denis, Sure, there's stuff in assembly that calls main. What I'm asking about is the stuff *inside* main that isn't in my code. As I see it, either: 1. The function I named "main" is at #02 on the above, in which case there are two subroutines that I didn't call on the stack. Then I'd like to know what they are, and whatever else anyone can tell me about them. 2. The function I named "main" is actually "rtdmain2mainrunMain", in which case (a) why was it renamed this horrible value; and (b) what other non-intuitive name manglings (!!) can I expect? (As if there was such a thing as an intuitive name mangling. :-) 3. The function I named "main" is actually "RegisterWaitForInputIdle", which will totally surprise me, in which case please explain why the stack trace is upside down, and why that name was chosen? =Austin
Oct 09 2010
parent Rainer Schuetze <r.sagitario gmx.de> writes:
Denis already explained the stack, here's some more info:

- cv2pdb demangles the function names, but uses ' ' instead of '.', 
because '.' in a symbol confuses the Visual Studio Debugger (I don't 
know why the ' ' is not displayed.)

- the D main function has symbol _Dmain, "main" is the C version in the 
runtime library

- RegisterWaitForInputIdle is probably just the exported symbol from 
ntdll.dll closest to the address found on the call stack. A lot of other 
code might be inbetween.

- you probably don't see the correct location of the throwing statement 
because the actually called function to do the throw is part of the 
phobos library. It is built without standard stack frame, so it's hard 
for a debugger (and probably the dumping function used here) to figure 
out the correct calling sequence.

- a bug report with patch is here: 
http://d.puremagic.com/issues/show_bug.cgi?id=4809

Rainer

Austin Hastings wrote:
 On 10/8/2010 6:47 PM, Denis Koroskin wrote:
 On Sat, 09 Oct 2010 02:36:30 +0400, Austin Hastings 
 <ah08010-d yahoo.com> wrote:

 object.Exception: Test
 ----------------
 00 rtdmain2mainrunMain
 01 rtdmain2mainrunAll
 02 main
 03 mainCRTStartup
 04 RegisterWaitForInputIdle

 Thanks for your help, Benjamin!

 My next question would be, why does the stack trace look this way? I'm
 throwing the exception from D's main. I assume that's entry #02. But
 what are the other two entries, and why are they on the stack?


 D main is not the true program entry point, there is a lot of
 preparation done (gc_init(), module init, etc) before your main() takes
 control, and these entries can be safely stripped since they are usually
 not what you are looking for.

Denis, Sure, there's stuff in assembly that calls main. What I'm asking about is the stuff *inside* main that isn't in my code. As I see it, either: 1. The function I named "main" is at #02 on the above, in which case there are two subroutines that I didn't call on the stack. Then I'd like to know what they are, and whatever else anyone can tell me about them. 2. The function I named "main" is actually "rtdmain2mainrunMain", in which case (a) why was it renamed this horrible value; and (b) what other non-intuitive name manglings (!!) can I expect? (As if there was such a thing as an intuitive name mangling. :-) 3. The function I named "main" is actually "RegisterWaitForInputIdle", which will totally surprise me, in which case please explain why the stack trace is upside down, and why that name was chosen? =Austin

Oct 10 2010
prev sibling next sibling parent "Yao G." <yao.gomez spam.gmail.com> writes:
On Wed, 06 Oct 2010 14:31:26 -0500, Benjamin Thaut  
<code benjamin-thaut.de> wrote:

 You have to compile with the -g option so that dmd produces debugging  
 symbols.
 Without symbols you will get just the addresses in your callstack.  
 Didn't check
 for warnings, will fix that.

 Kind Regards
 Benjamin Thaut

Yes. I'm compiling with the -g switch. -- Yao G.
Oct 06 2010
prev sibling next sibling parent "Yao G." <yao.gomez spam.gmail.com> writes:
I forgot to mention. I'm compiling the file using:

 dmd test.d C:\dmd\src\stacktrace.d C:\dmd\src\dbghelp.d -g -w

-- Yao G.
Oct 06 2010
prev sibling next sibling parent "Yao G." <yao.gomez spam.gmail.com> writes:
On Wed, 06 Oct 2010 15:22:18 -0500, Benjamin Thaut  
<code benjamin-thaut.de> wrote:

 Can you please check which version of dbghelp.dll is installed on your  
 system?

The version in the WINDOWS\System32\folder is 5.1.2600.5512.
 Which exact version of XP do you use? (service pack, x86/x64)?

Windows XP Pro Service Pack 3. x86 I think that some process is hooked and interfering with the debugging facilities. Since I installed the Visual Studio 2008 Shell, whenever a program crashes, the VS Debugger automatically fires up and ask me to allow it to debug or disassemble the core dump. Maybe is something related to that. -- Yao G.
Oct 06 2010
prev sibling next sibling parent "Yao G." <yao.gomez spam.gmail.com> writes:
My previous assumption was wrong. The problem was the ancient dbghelp.dl=
l  =

that comes with Windows XP. I copied, for testing purposes, one newer  =

version of said file (6.7.5.0) into the folder where the .exe is created=
  =

and voil=C3=A0, stacktracing now works:

object.Exception: Test
----------------
00 extern (C) int rt.dmain2.main(int, char**) . void runMain() .
01 extern (C) int rt.dmain2.main(int, char**) . void runAll() .
02 main
03 mainCRTStartup
04 RegisterWaitForInputIdle

I'm sorry for the noise. And thanks again for this! It will come very ve=
ry  =

handy when debugging my own code.

-- =

Yao G.
Oct 06 2010
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 06 Oct 2010 15:50:25 +0400, Benjamin Thaut  
<code benjamin-thaut.de> wrote:

 I wrote a small piece of sourcecode that generates stacktraces in D 2.0  
 under
 windows. It works both with the pdb and cv debug symbol format. For  
 Exceptions
 that are derived from the Error class the trace information is  
 automatically
 appended, this causes all builtin D errors to get a stacktrace  
 information.
 The only point where this does not work is the Access Vioaltion error,  
 as it
 does not call the stacktrace callback function for some reason.

 It is very easy to use, just copy the two files from the zip archive to  
 your
 root source directory and import the stacktrace module inside your main  
 file.
 For more informaiton and the download go to:
 http://3d.benjamin-thaut.de

 Let me know what you think.

 Kind Regards
 Benjamin Thaut

I modified druntime to support stack-tracing for all kind of exceptions. It's very simple: 1) In object_.d, change traceContext() function linkage to C: extern(C) Throwable.TraceInfo traceContext(void* ptr = null) { ... } 2) In rt\deh.c, declare Interface* traceContext(void* ptr); and add the following line to _d_create_exception_object (rt\deh.c) exc->info = traceContext(NULL); that's it. Works like a charm!
Oct 08 2010
parent reply Sean Kelly <sean invisibleduck.org> writes:
Denis Koroskin Wrote:
 
 I modified druntime to support stack-tracing for all kind of exceptions.  
 It's very simple:
 
 1) In object_.d, change traceContext() function linkage to C:
 extern(C) Throwable.TraceInfo traceContext(void* ptr = null) { ... }
 
 2) In rt\deh.c, declare
 Interface* traceContext(void* ptr);
 
 and add the following line to _d_create_exception_object (rt\deh.c)
 exc->info = traceContext(NULL);
 
 that's it. Works like a charm!

Pretty slick. I've been thinking about generating traces when the throw occurs instead of when the exception is constructed, and this change allows that as well. I'll add it to the queue.
Oct 08 2010
parent Kagamin <spam here.lot> writes:
Sean Kelly Wrote:

 Pretty slick.  I've been thinking about generating traces when the throw
occurs instead of when the exception is constructed, and this change allows
that as well.  I'll add it to the queue.

Then may be we should have Throwable.OnThrow function? One can make a good use of it. For example what if I want to do custom logging on throw?
Oct 11 2010
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 09 Oct 2010 02:36:30 +0400, Austin Hastings <ah08010-d yahoo.com>  
wrote:

 On 10/8/2010 2:46 AM, Benjamin Thaut wrote:

 Hm I don't have a XP machine to test on. But as Symbol 04 is resolved,
 it seems to work. It just can not resolve symbols inside your
 application. There is no upper limit to dbghelp.dll. I'm on Windows 7
 with dbghelp version 6.1.7600.16385. Most likely the probelm are the CV
 debugging symbols, as it was kind of hacky to get it to read those. Try
 converting your application with cv2pdb to pdb debugging symbols and see
 if this fixes the problem.

I ran cv2pdb.exe on the binary, and that works a treat: object.Exception: Test ---------------- 00 rtdmain2mainrunMain 01 rtdmain2mainrunAll 02 main 03 mainCRTStartup 04 RegisterWaitForInputIdle Thanks for your help, Benjamin! My next question would be, why does the stack trace look this way? I'm throwing the exception from D's main. I assume that's entry #02. But what are the other two entries, and why are they on the stack? =Austin

D main is not the true program entry point, there is a lot of preparation done (gc_init(), module init, etc) before your main() takes control, and these entries can be safely stripped since they are usually not what you are looking for.
Oct 08 2010
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 10 Oct 2010 02:52:06 +0400, Austin Hastings <ah08010-d yahoo.com>  
wrote:

 On 10/8/2010 6:47 PM, Denis Koroskin wrote:
 On Sat, 09 Oct 2010 02:36:30 +0400, Austin Hastings  
 <ah08010-d yahoo.com> wrote:

 object.Exception: Test
 ----------------
 00 rtdmain2mainrunMain
 01 rtdmain2mainrunAll
 02 main
 03 mainCRTStartup
 04 RegisterWaitForInputIdle

 Thanks for your help, Benjamin!

 My next question would be, why does the stack trace look this way? I'm
 throwing the exception from D's main. I assume that's entry #02. But
 what are the other two entries, and why are they on the stack?


 D main is not the true program entry point, there is a lot of
 preparation done (gc_init(), module init, etc) before your main() takes
 control, and these entries can be safely stripped since they are usually
 not what you are looking for.

Denis, Sure, there's stuff in assembly that calls main. What I'm asking about is the stuff *inside* main that isn't in my code. As I see it, either: 1. The function I named "main" is at #02 on the above, in which case there are two subroutines that I didn't call on the stack. Then I'd like to know what they are, and whatever else anyone can tell me about them. 2. The function I named "main" is actually "rtdmain2mainrunMain", in which case (a) why was it renamed this horrible value; and (b) what other non-intuitive name manglings (!!) can I expect? (As if there was such a thing as an intuitive name mangling. :-) 3. The function I named "main" is actually "RegisterWaitForInputIdle", which will totally surprise me, in which case please explain why the stack trace is upside down, and why that name was chosen? =Austin

There is no your main in that stack trace, it looks like it got ignored or something. Try more nested example. Stack trace is indeed upside-down. 04 I've no idea what RegisterWaitForInputIdle is, just ignore it. 03 mainCRTStartup is any C/C++/D (i.e. any C-based programming language) program entry point. C runtime library gets initialized. 02 main is an "extern (C) int main(int argc, char** argv)", defined in rt\dmain2.d (part of druntime source). This is where any C/C++/D executable starts. In D, this is where Garbage Collector gets initialized, module constructors, unittests ran etc 01 rtdmain2mainrunAll that's just a helper function that is called by main 00 rtdmain2mainrunMain - ditto, a try/catch wrapper around YOUR main -1 main - this one got lost for some reason In other words, here is how main looks like in D (slightly simplified): extern (C) int main(int argc, char** argv) // 02 { void runAll() // 01 { gc_init(); initStaticDataGC(); _minit(); _moduleCtor(); _moduleTlsCtor(); if (runModuleUnitTests()) runMain(); else result = EXIT_FAILURE; _moduleTlsDtor(); thread_joinAll(); _d_isHalting = true; _moduleDtor(); gc_term(); } void runMain() // 00 { result = main(args); // -1 } tryExec(&runAll); return result; } int main(string[] args); // -1, your main See http://dsource.org/projects/druntime/browser/trunk/src/rt/dmain2.d#L324 for full source code. Hope that helps.
Oct 09 2010
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 06 Oct 2010 15:50:25 +0400, Benjamin Thaut  
<code benjamin-thaut.de> wrote:

 I wrote a small piece of sourcecode that generates stacktraces in D 2.0  
 under
 windows. It works both with the pdb and cv debug symbol format. For  
 Exceptions
 that are derived from the Error class the trace information is  
 automatically
 appended, this causes all builtin D errors to get a stacktrace  
 information.
 The only point where this does not work is the Access Vioaltion error,  
 as it
 does not call the stacktrace callback function for some reason.

 It is very easy to use, just copy the two files from the zip archive to  
 your
 root source directory and import the stacktrace module inside your main  
 file.
 For more informaiton and the download go to:
 http://3d.benjamin-thaut.de

 Let me know what you think.

 Kind Regards
 Benjamin Thaut

I noticed your stacktraces should symbols but no file name/line numbers. I've sent another Stacktracer implementation to Phobos mailing list recently that primarily shows file name/line number while manually parsing .map file for symbolic info and shows none if .map file is absent. That was being criticized, and I agree with it. It also doesn't depend on dbghelp.dll and is able to show sane results even when the said .dll is missing. I think we could merge our projects, taking advantages from both. What do you think?
Oct 10 2010
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 10.10.2010 21:31, schrieb Denis Koroskin:
 On Wed, 06 Oct 2010 15:50:25 +0400, Benjamin Thaut
 <code benjamin-thaut.de> wrote:

 I wrote a small piece of sourcecode that generates stacktraces in D
 2.0 under
 windows. It works both with the pdb and cv debug symbol format. For
 Exceptions
 that are derived from the Error class the trace information is
 automatically
 appended, this causes all builtin D errors to get a stacktrace
 information.
 The only point where this does not work is the Access Vioaltion error,
 as it
 does not call the stacktrace callback function for some reason.

 It is very easy to use, just copy the two files from the zip archive
 to your
 root source directory and import the stacktrace module inside your
 main file.
 For more informaiton and the download go to:
 http://3d.benjamin-thaut.de

 Let me know what you think.

 Kind Regards
 Benjamin Thaut

I noticed your stacktraces should symbols but no file name/line numbers. I've sent another Stacktracer implementation to Phobos mailing list recently that primarily shows file name/line number while manually parsing .map file for symbolic info and shows none if .map file is absent. That was being criticized, and I agree with it. It also doesn't depend on dbghelp.dll and is able to show sane results even when the said .dll is missing. I think we could merge our projects, taking advantages from both. What do you think?

My stackwalker does show filenames and line numbers but you need to compile with -g -debug so that there is line/file information in the symbols. If you look at the example stacktrace at http://3d.benjamin-thaut.de/?p=15 you can see filenames and line numbers -- Kind Regards Benjamin Thaut
Oct 11 2010