[Issue 8841] Missing line numbers in stack trace?

2020-01-16 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8841

Mathias LANG  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||pro.mathias.l...@gmail.com
 Resolution|--- |FIXED

--- Comment #10 from Mathias LANG  ---
This works now.

--


[Issue 8841] Missing line numbers in stack trace?

2018-09-10 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8841

Heromyth  changed:

   What|Removed |Added

 CC||bitwo...@qq.com

--- Comment #9 from Heromyth  ---
It seems fixed.

--


[Issue 8841] Missing line numbers in stack trace?

2017-08-21 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8841

Gerald Jansen  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17727

--


[Issue 8841] Missing line numbers in stack trace?

2017-07-01 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8841

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=13726

--


[Issue 8841] Missing line numbers in stack trace?

2012-12-26 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8841


Russel Winder rus...@winder.org.uk changed:

   What|Removed |Added

 CC||rus...@winder.org.uk


--- Comment #7 from Russel Winder rus...@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: ---


[Issue 8841] Missing line numbers in stack trace?

2012-12-23 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8841



--- Comment #6 from Rainer Schuetze r.sagita...@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: ---


[Issue 8841] Missing line numbers in stack trace?

2012-12-22 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8841


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
   Severity|regression  |normal


--- Comment #5 from Walter Bright bugzi...@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: ---


[Issue 8841] Missing line numbers in stack trace?

2012-12-16 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8841



--- Comment #3 from Kenji Hara k.hara...@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: ---


[Issue 8841] Missing line numbers in stack trace?

2012-12-16 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8841


Rainer Schuetze r.sagita...@gmx.de changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de


--- Comment #4 from Rainer Schuetze r.sagita...@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: ---


[Issue 8841] Missing line numbers in stack trace?

2012-10-18 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8841



--- Comment #2 from bearophile_h...@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: ---


[Issue 8841] Missing line numbers in stack trace?

2012-10-17 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=8841


Brad Roberts bra...@puremagic.com changed:

   What|Removed |Added

 CC||bra...@puremagic.com


--- Comment #1 from Brad Roberts bra...@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: ---