void main() { int[] foo; auto bar = new int[10]; foo[] = bar[]; } I don't know if my self-compiled alpha-dmd is broken, or if I am just doing something wrong, but I am not seeing line numbers nor Dmain: DMD 2.061alpha: ...>dmd -g test.d ...>test object.Error: lengths don't match for array copy ---------------- 0x0040C068 in char[][] core.sys.windows.stacktrace.StackTrace.trace() 0x0040BEF3 in core.sys.windows.stacktrace.StackTrace core.sys.windows.stacktrace.StackTrace.__ctor() 0x004025E8 in _d_arraycopy 0x00402554 in extern (C) int rt.dmain2.main(int, char**).void runMain() 0x0040258E in extern (C) int rt.dmain2.main(int, char**).void runAll() 0x004021A2 in main 0x00413A81 in mainCRTStartup 0x76FFD309 in BaseThreadInitThunk 0x77411603 in RtlInitializeExceptionChain 0x774115D6 in RtlInitializeExceptionChain ----------------
Did your build of any past version work correctly on your box? If not, it's not a regression. If so, then please use git bisect to determine what commit introduced the regression.
(In reply to comment #1) > Did your build of any past version work correctly on your box? I used to see line numbers.
This seems a regression in 2.060. This code: ---- void main() { assert(0); } ---- With 2.059: > dmd -g -run test.d core.exception.AssertError@test(5): Assertion failure ---------------- C:\Users\khara\d\test.d(6): _Dmain ---------------- With 2.060: > dmd -g -run test.d core.exception.AssertError@test(5): Assertion failure ---------------- 0x0040BF5C in char[][] core.sys.windows.stacktrace.StackTrace.trace() 0x0040BDE7 in core.sys.windows.stacktrace.StackTrace core.sys.windows.stacktrace.StackTrace.__ctor() 0x00403353 in onAssertError 0x0040201D in _Dmain at C:\Users\khara\d\test.d(5) 0x00402530 in extern (C) int rt.dmain2.main(int, char**).void runMain() 0x0040256A in extern (C) int rt.dmain2.main(int, char**).void runAll() 0x0040218C in main 0x00413745 in mainCRTStartup 0x7640ED6C in BaseThreadInitThunk 0x77DD377B in RtlInitializeExceptionChain 0x77DD374E in RtlInitializeExceptionChain ---------------- But I'm not sure which druntime change changed the result...
I don't think it is a regression, it has always been rather indeterministic whether the location of throwing code is shown. It very much depends on the type of exception and whether you are using a release or debug version of the runtime lib. This is happening because the stack walker cannot easily walk the stack of runtime library functions that are built without standard stack frame. It would need "frame pointer omission records" to do that properly, but these are not generated by dmd. There has been some work to solve this in 2.060, but it didn't improve the situation a lot.
I don't see this as having ever worked, as I tried it with 2.059 and 2.060 and no line numbers were produced for the stack trace for the first example.
The callstack for the original example does not show line numbers because the functions shown are all from the runtime library which is not compiled with debug information. The major problem is that the throwing statement in main isn't shown at all. If it is shown (as in Kenjis example) line numbers usually show up.
With LDC2, changing the thread creation to include .array makes the code work. There is no need for the ii → i change in the creation of the closure.
> The major problem is that the throwing statement in main isn't shown at all. If > it is shown (as in Kenjis example) line numbers usually show up. I noticed this issue as well. As it seems dmd does not generate a propper stackframe when calling druntime c-functions. The same happens with assert. Only onAssertError will appear on the callstack, but not the function that did trigger the assert. But nothing can be done on the runtime side about this. To make this work dmd would have to generate stackframes that are valid for StackWalk64. In x64 this works just fine, all called functions show up (as soon as this is merged https://github.com/D-Programming-Language/druntime/pull/368)
It seems fixed.
This works now.