Thread overview
[Issue 8841] New: Missing line numbers in stack trace?
Oct 18, 2012
Brad Roberts
Dec 17, 2012
Kenji Hara
Dec 17, 2012
Rainer Schuetze
Dec 23, 2012
Walter Bright
Dec 23, 2012
Rainer Schuetze
Dec 26, 2012
Russel Winder
Feb 09, 2013
Benjamin Thaut
October 17, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8841

           Summary: Missing line numbers in stack trace?
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Severity: regression
          Priority: P2
         Component: druntime
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2012-10-17 15:28:33 PDT ---
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
----------------

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 18, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8841


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |braddr@puremagic.com


--- Comment #1 from Brad Roberts <braddr@puremagic.com> 2012-10-17 22:37:47 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 18, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8841



--- Comment #2 from bearophile_hugs@eml.cc 2012-10-18 01:37:09 PDT ---
(In reply to comment #1)
> Did your build of any past version work correctly on your box?

I used to see line numbers.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
December 17, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8841



--- Comment #3 from Kenji Hara <k.hara.pg@gmail.com> 2012-12-16 23:11:49 PST ---
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...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
December 17, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8841


Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario@gmx.de


--- Comment #4 from Rainer Schuetze <r.sagitario@gmx.de> 2012-12-16 23:39:11 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
December 23, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8841


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com
           Severity|regression                  |normal


--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> 2012-12-22 17:35:02 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
December 23, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8841



--- Comment #6 from Rainer Schuetze <r.sagitario@gmx.de> 2012-12-23 05:27:46 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
December 26, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=8841


Russel Winder <russel@winder.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |russel@winder.org.uk


--- Comment #7 from Russel Winder <russel@winder.org.uk> 2012-12-26 07:13:39 PST ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
February 09, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=8841


Benjamin Thaut <code@benjamin-thaut.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@benjamin-thaut.de


--- Comment #8 from Benjamin Thaut <code@benjamin-thaut.de> 2013-02-09 10:05:46 PST ---
> 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)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------