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 "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 parent reply "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
next sibling parent reply 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
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 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 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


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.

-- 
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 

what are the other two entries, and why are they on the stack?

=Austin
Oct 08 2010
parent reply "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  

 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
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

 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:


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
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

 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:


 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 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

 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:
 

 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 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 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