Bug creation and email sending has been disabled, file new bugs at gcc.gnu.org/bugzilla
Bug 98 - MinGW: stack trace on exception needs enhanced
Summary: MinGW: stack trace on exception needs enhanced
Status: NEW
Alias: None
Product: GDC
Classification: Unclassified
Component: gdc (show other bugs)
Version: development
Hardware: x86 MinGW
: --- minor
Assignee: Iain Buclaw
URL:
Depends on:
Blocks:
 
Reported: 2014-02-01 10:41 CET by Mike
Modified: 2014-02-01 10:41 CET (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike 2014-02-01 10:41:00 CET
Daniel Green created an issue 2012-06-12
*****************************************
D introduced a stack trace feature on exceptions. Currently, this will only list address of the function and no additional information.

This should be enhanced for MinGW 32/64 to return better output for GDC.

The MinGW64 version would also crash upon execution of StackWalk64 after a Fiber context switch.

This occurred on the first call(suggestive that is a windows issue?) and may have been related to unapplied Windows Updates.

However, due to the following stack disappearance with GDB this will remain disabled until it this issue has been resolved or proof that it was a Microsoft bug.

#0  _d_throw (obj=...) at ../../../../gcc-4.6.1/libphobos/libdruntime/gcc/deh.d:153
#1  0x0000000000420853 in onAssertErrorMsg (file=..., line=53, msg=...) at ../../../../gcc-4.6.1/libphobos/libdruntime/core/exception.d:421
#2  0x0000000000411382 in _d_assert_msg (msg=..., file=) at ../../../../gcc-4.6.1/libphobos/libdruntime/rt/dmain2.d:203
#3  0x0000000000401659 in D main () at issue342.d:53
#4  0x00000000004126a2 in rt.dmain2._d_run_main.runMain (this=0x22fda0) at ../../../../gcc-4.6.1/libphobos/libdruntime/rt/dmain2.d:574
#5  0x0000000000411fe1 in rt.dmain2._d_run_main.tryExec (this=0x22fda0, dg=...) at ../../../../gcc-4.6.1/libphobos/libdruntime/rt/dmain2.d:549
#6  0x0000000000000000 in ?? () <- This is invalid.  Where's the rest of the call stack?

When compared to the values given by StackWalk64. It's missing 4 frames of stack information lost upon calling rt.dmain2._d_run_main.tryExec. Prior to the use of Fibers. This symptom was not exhibited by MinGW32.

40FF74
409BDB
411176
418F0F
411382
401659
4126A2
411FE1
41271E
411FE1 <- last GDB entry
411D35
401735
4013CE
4014E8