My previous assumption was wrong. The problem was the ancient dbghelp.dll 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à, 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 very handy when debugging my own code.

-- 
Yao G.

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

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

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!

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.

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

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.

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

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.

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