www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 8841] New: Missing line numbers in stack trace?

reply d-bugmail puremagic.com writes:
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: -------
Oct 17 2012
next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 17 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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

---------------- C:\Users\khara\d\test.d(6): _Dmain ---------------- With 2.060:
 dmd -g -run test.d

---------------- 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: -------
Dec 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Dec 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Dec 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Dec 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Dec 26 2012
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Feb 09 2013