Bug 20702 – Strack trace points to exception ctor instead of throw statement

Consider the following code: --------------------------------- module build; void main() { throw new Exception(""); } --------------------------------- dmd -g -m64 -run test.d object.Exception@.\build.d(3) ---------------- 0x00007FF79458BBA9 in D main at C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d(1976) 0x00007FF79458E303 in void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll().__lambda1() 0x00007FF79458E13C in void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).tryExec(scope void delegate()) 0x00007FF79458E23B in void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() 0x00007FF79458E13C in void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).tryExec(scope void delegate()) 0x00007FF79458DF73 in d_run_main2 0x00007FF79458C740 in d_run_main 0x00007FF79458BBF2 in build._d_cmain!().main at C:\D\dmd2\windows\bin\..\..\src\druntime\import\core\internal\entrypoint.d(29) 0x00007FF7945D79FC in __scrt_common_main_seh at d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288) 0x00007FF9D8417BD4 in BaseThreadInitThunk 0x00007FF9DA24CED1 in RtlUserThreadStart The first line correctly lists the main function but prints the location of Exception's constructor. -------------------------------- dmd -g -m32 -run test.d object.Exception@.\build.d(3) ---------------- 0x004022B4 in _Dmain 0x00402883 in void rt.dmain2._d_run_main2(char[][], uint, extern (C) int function(char[][])*).runAll().__lambda1() 0x004027FD in void rt.dmain2._d_run_main2(char[][], uint, extern (C) int function(char[][])*).runAll() 0x00402696 in _d_run_main2 0x00402402 in _d_run_main 0x004022CC in main at C:\D\dmd2\windows\bin\..\..\src\druntime\import\core\internal\entrypoint.d(29) 0x00425ED5 in mainCRTStartup 0x76676359 in BaseThreadInitThunk 0x77697B74 in RtlGetAppContainerNamedObjectPath 0x77697B44 in RtlGetAppContainerNamedObjectPath The location is omitted entirely for 32bit builds. --------------------------------- dmd -g -m32mscoff build.d object.Exception@.\build.d(3) ---------------- 0x0043BAD4 in D main at E:\\build-only.reduced\build.d(3) 0x0043CC9B in void rt.dmain2._d_run_main2(char[][], uint, extern (C) int function(char[][])*).runAll().__lambda1() 0x0043CBD5 in void rt.dmain2._d_run_main2(char[][], uint, extern (C) int function(char[][])*).runAll() 0x0043C9C8 in _d_run_main2 0x0043BDA6 in _d_run_main 0x0043BAF8 in build._d_cmain!().main at C:\D\dmd2\windows\bin\..\..\src\druntime\import\core\internal\entrypoint.d(29) 0x00479738 in __scrt_common_main_seh at d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288) 0x76676359 in BaseThreadInitThunk 0x77697B74 in RtlGetAppContainerNamedObjectPath 0x77697B44 in RtlGetAppContainerNamedObjectPath mscoff seems fine.

What are the compiler versions you tested with ? It might be me, if it's a regression: https://github.com/dlang/druntime/pull/2724 To be fair the hard-coded count of frame is very brittle and should be replaced with something more robust that looks at the symbol.

dmd --version DMD64 D Compiler v2.091.0-dirty

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19686 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB