Bug 4809 – Stack trace when throwing exception misses location of the throw statement

Under windows, the following code void func1() { throw new Exception("msg"); } void main() { func1(); } shows this stack frame (debug info run through cv2pdb) when intercepting throwing exceptions: kernel32.dll!_RaiseException@16() + 0x52 bytes test.exe!_d_throw(Object & h={...}) Line 238 C++ > testexe!_Dmain() Line 7 + 0x5 bytes C++ test.exe!rt@dmain2@main@runMain() + 0xb bytes C++ test.exe!rt@dmain2@main@runAll() + 0xe bytes C++ test.exe!main(int argc=1, char * * argv=0x008a03c4) C++ test.exe!_mainCRTStartup() + 0xa9 bytes C++ kernel32.dll!_BaseProcessStart@4() + 0x23 bytes i.e. it is missing the function actually throwing the exception. This is caused by _d_throw not having a standard stack frame. _d_throw is defined in deh.c and should be compiled with forcing standard stack frames using option "-S": deh.obj : src\rt\deh.c - $(CC) -c $(CFLAGS) src\rt\deh.c + $(CC) -c $(CFLAGS) -S src\rt\deh.c

The patch here is no longer valid, because deh.c has been translated to d some time back. Instead, use this: https://github.com/D-Programming-Language/druntime/pull/80

Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/80625a2fc87a830aa538f2f58579019c661ceac9 Merge pull request #80 from rainers/issue4809 Issue 4809: Help the stack walker to find the location of a throw statement

Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/dcc5a08e8b4ac9de869d727ceea3d407c7f92d00 Revert "Merge pull request #80 from rainers/issue4809" This reverts commit 80625a2fc87a830aa538f2f58579019c661ceac9, reversing changes made to ce783fff516d21c253edfecb40982c833add3e4b. https://github.com/D-Programming-Language/druntime/commit/0baa13d9df06b0a27e9b8004ecdd5e8ef338adae fix Issue 4809 - set up a stackframe for _d_throwc so that the caller is listed in the trace

According to the commit date and the changelog, this should be fixed since dmd 2.061. (I also tested it now with the reported test case).