digitalmars.D.bugs - [Issue 1001] New: print stack trace (in debug mode) when program die
- d-bugmail puremagic.com (15/15) Feb 22 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (5/5) Feb 22 2007 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (10/10) Jan 17 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (13/13) Feb 02 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (13/13) Feb 02 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (15/15) Feb 02 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (9/10) Feb 02 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (42/42) Feb 03 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (38/38) Feb 04 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (8/8) Feb 04 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (22/22) Feb 04 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (13/13) Feb 04 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (13/13) Feb 04 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (31/41) Feb 04 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (8/8) Feb 04 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (17/20) Feb 05 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (11/11) May 05 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (7/7) May 05 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (10/10) May 06 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (54/54) May 25 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (6/6) May 25 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (6/6) May 25 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (24/24) May 26 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (15/24) May 26 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (12/12) May 29 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (57/57) May 31 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (29/29) Aug 22 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (18/18) Aug 22 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (20/20) Aug 23 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (14/14) Aug 23 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (7/7) Sep 09 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (8/8) Sep 16 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (13/23) Oct 02 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (13/13) Oct 07 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (35/37) Nov 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (16/19) Jan 20 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (8/8) Mar 15 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- Sean Kelly (2/11) Mar 16 2011 Next release.
- d-bugmail puremagic.com (8/12) Mar 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (7/7) Mar 24 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (16/16) May 20 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (7/7) May 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (7/9) May 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (10/10) May 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (9/9) May 23 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (8/8) May 24 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (6/6) Jul 03 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (12/12) Jul 03 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (7/7) Aug 09 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (21/21) Aug 18 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (7/7) Aug 18 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (7/7) Aug 18 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (10/12) Aug 18 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (8/12) Aug 18 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (8/8) Aug 19 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (7/7) Dec 01 2011 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (13/15) Jan 06 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (6/6) Jul 24 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (18/18) Jul 24 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (7/7) Dec 23 2012 http://d.puremagic.com/issues/show_bug.cgi?id=1001
- d-bugmail puremagic.com (16/26) May 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=1001
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Summary: print stack trace (in debug mode) when program die
Product: D
Version: unspecified
Platform: PC
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: bugzilla digitalmars.com
ReportedBy: someanon yahoo.com
Just as Java, it's a great life saver in development, especially when we don't
have a decent debugger right now.
--
Feb 22 2007
d-bugmail puremagic.com http://d.puremagic.com/issues/show_bug.cgi?id=1001 The Flectioned runtime reflection library (http://flectioned.kuehne.cn/) can provide this, though language support would be welcome. --
Feb 22 2007
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Hoenir <mrmocool gmx.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mrmocool gmx.de
Flectioned hasn't been updated since over 2 years though.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 17 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Sean Kelly <sean invisibleduck.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
---
Flectioned doesn't work any more I'm afraid. A replacement would be welcome,
though I may be able to sort something out quickly with the stuff in ucontext.h
on *nix. Some platforms even have a backtrace call here, though output is
fixed to a specific format.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 02 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
BCS <shro8822 vandals.uidaho.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |shro8822 vandals.uidaho.edu
---
does anyone know if the "backtrace" function from execinfo.h works with
DMD/Linux?
If it does, than that's the way to go. Heck, I've even got a blob of CPP code
I'd give way that calls addr2line to get nice output.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 02 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Brad Roberts <braddr puremagic.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |braddr puremagic.com
---
The c function works, so it will work with dmd. I've been meaning to hook the
thing into the runtime for ages. It's easy to use. The only interesting trick
is that the app needs to be linked with -rdynamic (check the man pages, this is
off the top of my head from when I've done it at work). That'll likely require
a minor tweak to dmd itself since it's what invokes the linker. It could
probably be added to dmd.conf as an alternative.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 02 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 ---The c function works, so it will work with dmd.It will work with extern C functions but something's ticking a memory that D functions aren't necessarily the same, or is that just the arguments layout? What the heck, I'll try it tomorrow and see if it works. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 02 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
---
Created an attachment (id=560)
first pass patch to add stack tracing for exceptions on linux
It's dumping filename (always the test binary name right now) and address, but
not function name for some reason.. at least on my debian amd/64 box. I'm not
sure yet why it's failing to find the symbols right now. I need to pull the
code over into a C app to make sure it works there. That'd at least help
narrow down where the problem lies.
Current output:
$ ./obj/posix/debug/unittest.brad
object.Exception: blah
----------------
./obj/posix/debug/unittest.brad [0x804b684]
./obj/posix/debug/unittest.brad [0x804b65c]
./obj/posix/debug/unittest.brad [0x804ab0b]
./obj/posix/debug/unittest.brad [0x804a8f0]
./obj/posix/debug/unittest.brad [0x804ab27]
./obj/posix/debug/unittest.brad [0x80491de]
./obj/posix/debug/unittest.brad [0x80491f0]
./obj/posix/debug/unittest.brad [0x804b93c]
./obj/posix/debug/unittest.brad [0x804b745]
./obj/posix/debug/unittest.brad [0x804b97e]
./obj/posix/debug/unittest.brad [0x804b745]
./obj/posix/debug/unittest.brad [0x804b603]
/lib32/libc.so.6(__libc_start_main+0xe6) [0xf7e02b46]
./obj/posix/debug/unittest.brad [0x8049101]
test code:
public import std.c.stdio;
void foo()
{
throw new Exception("blah");
}
int main(char[][] args)
{
foo();
printf("Success!\n");
return 0;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 03 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 --- printstack doesn't exist on OSX, so it has to be faked there (which is pretty easy to do). The only trick is that the stack trace integration is line-based using opApply, so on platforms where backtrace isn't available, the trace should really be output to a buffer and then parsed for opApply output. This might not be possible with printstack though. In any case, here's some code I've used to mimic printstack on OSX. The backtrace_symbols call is what I'd use for opApply, since it's pretty much exactly what's needed. If I remember correctly, backtrace is just a wrapper for some of the stuff in <ucontext.h>. #if defined(sun) || defined(__sun) || defined(_sun_) || defined(__solaris__) #elif defined(__APPLE__) int printstack( int fd ) { void* callstack[128]; int frames = backtrace( callstack, 128 ); backtrace_symbols_fd( callstack, frames, fd ); /* char** strs = backtrace_symbols( callstack, frames ); for( i = 0; i < frames; ++i ) { fprintf( fd, "%s\n", strs[i] ); } free( strs ); */ return 0; } #else int printstack( int fd ) { return 0; } #endif -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 04 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Oops! Looks like Brad beat me to it. So it looks like backtrace is available on both OSX and Linux. I guess that leaves us needing backtrace support on Win32. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 04 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Witold Baryluk <baryluk smp.if.uj.edu.pl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |baryluk smp.if.uj.edu.pl
16:41:22 PST ---
It would be greate to have similar flexibiliy like in flectioned:
- allow to have all exception be tracable or not, using runtime or compile
switches,
- or always trace only this exceptions which are derived from TracedException
- have interface to get stacktrace from catched TracedException object (in
case of normal Exceptions, with runtime/compile enabled stacktraces for all
Exceptions it still should be possible to call such method, but it should
return error, empty list, null StackTrace object, or ... give exception.).
rationale for this is that backtrace construction is slow probably, and EH is
already slow, but EH is used extensivly sometimes for flow control (i know it
is wrong aproach), but backtrace will most probably triple this cost.
exception handling is also used internally for things like destructions of
scope variables.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 04 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
16:48:33 PST ---
AFAIK on freebsd it my be needed to link with -lexecinfo
and according to my manual:
These functions are GNU extensions.
and:
backtrace(), backtrace_symbols(), and backtrace_symbols_fd() are
provided in glibc since version 2.1.
So one should consult interfaces and implementation with LDC team and Tango
team.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 04 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PST --- Stack tracing is integrated with Throwable now, so if it's enabled it will happen for all exceptions that are created with "new" (ie. it won't happen on OutOfMemory). It can either be shipped as a standalone library so the user has to link it, or it can be enabled/disabled via a code statement, something like: Runtime.traceHandler = defaultTraceHandler; // turn on Runtime.traceHandler = null; // turn off The runtime property is already there, so it would just be a matter of exposing "defaultTraceHandler". -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 04 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 17:19:01 PST ---Stack tracing is integrated with Throwable now, so if it's enabled it will happen for all exceptions that are created with "new" (ie. it won't happen on OutOfMemory). It can either be shipped as a standalone library so the user has to link it, or it can be enabled/disabled via a code statement, something like: Runtime.traceHandler = defaultTraceHandler; // turn on Runtime.traceHandler = null; // turn off The runtime property is already there, so it would just be a matter of exposing "defaultTraceHandler".IMHO it is not sufficient. It is global switch, will change behaviour of all exceptions (beyond few system errors). What is problematic is that one can have implementation of something (ie. iterators) which uses havily exceptions (throw new ... them milion per second). If this part of code is already tested we don't want to trace stack for this control-exceptions becuase it is pointless and can for example slow down code by order of magnitude (just a guess). Possible solutions: - do not throw new object: save somewhere throwed object, and when back to throw it again similar control exception, throw really buffered object (this way we will not call constructor of exception). - have a way to specify which exceptions are traced, this can be done in multiple ways: - trace all, minus blacklisted classes (defined in runtime or using derivation from some class) - trace none, plus whitelisted classes (as above). It would be also usefull to have handler of SIGSEGV signal which will show trace of the thread/process which done something wrong. Also INT3 is intersting to have. In flectioned (which is nice, but really hackish, have ELF parser, lots of asembler and whiteliste of many functions), this is solved using (phobos part); - tracing only of exceptions derived from flectioned.TracedException - and optionally tracing all exception by calling first flectioned.TracedException.traceAllExceptions(true); Well maybe You have better ideas :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 04 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PST --- Exception handling is for error conditions, not flow control. If someone is actually constructing exceptions for some other purpose then they're using the wrong tool :-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 04 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 05:28:30 PST ---Exception handling is for error conditions, not flow control. If someone is actually constructing exceptions for some other purpose then they're using the wrong tool :-)Well, yes you are right. I just checked my old code which i was thinking is using heavly EH for flow control. But I wasn't so stupid :) EH is only used for escaping in rare ocasions (not for error conditions but for flow control, yes, but i'm comparing more throw here to break; like in for/while, than to continiue :) ) Sorry for the problem. Anyway in documentation of this functionality I think there should be the statment that stacktrace is only intended to help in debuging and crash reporting, and no code should directly depend on the fact that returned backtrace is nonempty or correct. (becuase in one can set traceHandler to null, or disabled it in -release mode for example). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 05 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
PDT ---
This can now be enabled by:
import core.runtime;
...
Runtime.traceHandler = &defaultTraceHandler;
I can't have it automatically set in debug mode because only a release version
of the lib is currently shipped.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 05 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- personally.. I'd suggest it just always be enabled. Maybe leave the hook but make it be something to turn off rather than on. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 05 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- Fair enough. To disable the trace handler you'll do: Runtime.traceHandler = null; I'm looking into adding trace functionality for Windows as well (probably using WalkStack64), but that's a bit trickier. I need to set up a Windows dev environment before I can even start on it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 06 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
PDT ---
Sean, any objection to me submitting this minor diff:
Index: src/object_.d
===================================================================
--- src/object_.d (revision 296)
+++ src/object_.d (working copy)
-1189,6 +1189,13
traceHandler = h;
}
+/**
+ * Return the current trace handler
+ */
+extern (C) TraceHandler rt_getTraceHandler()
+{
+ return traceHandler;
+}
/**
* This function will be called when an exception is constructed. The
Index: src/core/runtime.d
===================================================================
--- src/core/runtime.d (revision 296)
+++ src/core/runtime.d (working copy)
-23,6 +23,7
extern (C) void rt_setCollectHandler( CollectHandler h );
extern (C) void rt_setTraceHandler( TraceHandler h );
+ extern (C) TraceHandler rt_getTraceHandler();
alias void delegate( Throwable ) ExceptionHandler;
extern (C) bool rt_init( ExceptionHandler dg = null );
-172,6 +173,13
rt_setTraceHandler( h );
}
+ /**
+ * Return the current trace handler
+ */
+ static TraceHandler traceHandler()
+ {
+ return rt_getTraceHandler();
+ }
/**
* Overrides the default collect hander with a user-supplied version.
This
This would enable code like this:
auto oldTH = Runtime.traceHandler;
Runtime.traceHandler = null;
scope(exit) Runtime.traceHandler = oldTH;
I ran across this 'need' while working on the dmd test suite that is checking
some object throwing results, specifically two asserts like this:
Object e = new Exception("hello");
assert(e.toString() == "object.Exception: hello");
assert(format(e) == "object.Exception: hello");
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 25 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- Not at all. We should really make all of the Runtime properties get/settable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 25 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- Submitted as svn r297. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 25 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
bearophile_hugs eml.cc changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bearophile_hugs eml.cc
This is an example of Python program that gives a stack trace (here I have used
a lambda also to show that stack trace printing code sometimes has problems
with anonymous functions):
reverser = lambda s: s[-1] + reverser(s[:-1]) if s else ""
print reverser("this is a test" * 200)
After battling with huge stack traces in Python, there's another feature that
I'd like to have in D (I am not sure if on default or not): stack trace
compression. If a recursive function keeps calling itself, or two functions
keep calling each other (other possibilities exist, but those two cover most
cases), the stack trace can become too much long to print and read.
So just looking at the latest stack frame printed and penultimate stack frame
printed it can compress it, reporting only how many time the last one or the
last two ones are repeated (the uncompressed stack trace can be obtained too
(on request if the compressed one is on default, otherwise it's the compressed
one that's on request), that shows all the line numbers too).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 26 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Don <clugdbug yahoo.com.au> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |clugdbug yahoo.com.au
If a recursive function keeps calling itself, or two functions
keep calling each other (other possibilities exist, but those two cover most
cases), the stack trace can become too much long to print and read.
So just looking at the latest stack frame printed and penultimate stack frame
printed it can compress it, reporting only how many time the last one or the
last two ones are repeated (the uncompressed stack trace can be obtained too
(on request if the compressed one is on default, otherwise it's the compressed
one that's on request), that shows all the line numbers too).
That's what's done with the template instantiation backtraces in the compiler,
and I think it works very well. The basic idea is to always print out the first
few frames, and only start looking for recursion beginning at frame 3 or 4.
I intend to add something similar to the interpreter, so that we have a CTFE
stack trace. Still needs work though.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 26 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- There's two big things left on my list for stacktraces (at least on linux) that need to be done: 1) the default dmd.conf needs to have -L--export-dynamic in it 2) the strings from backtrace_symbols need to be demangled Any collapsing of recursion is a distant second in my opinion. Obviously, for those that use windows, traces on windows would probably go -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 29 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- Created an attachment (id=650) sort hacky move of demangle from phobos to druntime and hook into the stacktrace code Arguably the demangler belongs in the runtime. The current code is, well, less than ideal. At least from an interface standpoint. But this get's the pieces moved and put together to demonstrate what it could be. In the process I also noticed that the current unittest for druntime fails, which is handy for testing. The results: <snip a bunch of foo unittest lines> _arraySliceSliceMulass_s unittest core.exception.AssertError gc.gcx(264): Assertion failure ---------------- ./unittest(class core.exception.AssertError core.exception.AssertError.__ctor(immutable(char)[], uint) . +0x25) [0x8077a65] ./unittest(onAssertError+0x28) [0x8077c18] ./unittest(_d_assertm+0x16) [0x8095c02] ./unittest(void gc.gcx.__assert(int) . +0x12) [0x807f46e] ./unittest(void gc.gcx.GC.enable() . +0x54) [0x807c930] ./unittest(gc_enable+0x16) [0x807be7e] ./unittest(void core.memory.GC.enable() . +0x8) [0x8077ea0] ./unittest(_Dmain+0x2b) [0x8074b17] ./unittest(extern (C) int rt.dmain2.main(int, char**) . void runMain() . +0x14) [0x8095f44] ./unittest(extern (C) int rt.dmain2.main(int, char**) . void tryExec(void delegate()) . +0x1d) [0x8095ea9] ./unittest(extern (C) int rt.dmain2.main(int, char**) . void runAll() . +0x2d) [0x8095f81] ./unittest(extern (C) int rt.dmain2.main(int, char**) . void tryExec(void delegate()) . +0x1d) [0x8095ea9] ./unittest(main+0x88) [0x8095e58] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x12bbd6] ./unittest() [0x80741a1] vs what it emitted before the changes: _arraySliceSliceMulass_s unittest core.exception.AssertError gc.gcx(264): Assertion failure ---------------- ./unittest(_D4core9exception11AssertError6__ctorMFAyakZC4core9exception11AssertError+0x25) [0x8077a65] ./unittest(onAssertError+0x28) [0x8077c18] ./unittest(_d_assertm+0x16) [0x8095be2] ./unittest(_D2gc3gcx8__assertFiZv+0x12) [0x807f426] ./unittest(_D2gc3gcx2GC6enableMFZv+0x54) [0x807c8e8] ./unittest(gc_enable+0x16) [0x807be36] ./unittest(_D4core6memory2GC6enableFZv+0x8) [0x8077ea0] ./unittest(_Dmain+0x2b) [0x8074b17] ./unittest(_D2rt6dmain24mainUiPPaZi7runMainMFZv+0x14) [0x8095f24] ./unittest(_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv+0x1d) [0x8095e89] ./unittest(_D2rt6dmain24mainUiPPaZi6runAllMFZv+0x2d) [0x8095f61] ./unittest(_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv+0x1d) [0x8095e89] ./unittest(main+0x88) [0x8095e38] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xd23bd6] ./unittest() [0x80741a1] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 31 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Jonathan M Davis <jmdavisProg gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jmdavisProg gmail.com
13:50:51 PDT ---
I don't know what the current state of stack traces is overall or where it is
with regards to work being done on them, but I would point out that all you get
on Linux right now is a list of addresses. e.g.
object.Exception gregorian.d(241): Invalid year.
----------------
./test() [0x805936a]
./test() [0x804b168]
./test() [0x804b269]
./test() [0x805b9fb]
./test() [0x8068d3c]
./test() [0x8060bed]
./test() [0x8068c57]
./test() [0x8061a88]
./test() [0x80619b0]
./test() [0x8061956]
/opt/lib32/lib/libc.so.6(__libc_start_main+0xe6) [0xf75cdc76]
./test() [0x8049341]
So, as it stands (using dmd 2.048), stack traces on Linux are pretty useless. I
would assume that Sean is aware of this, but I thought that I should post a
reminder of the current state of stack traces on Linux.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 22 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
nfxjfg gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nfxjfg gmail.com
Note that Tango has a full implementation for backtraces both on Windows and
Linux with demangled function names, files and line numbers. They are shown on
uncatched exceptions, segfaults, or when explicitly requested. Only
requirements are that the D program got compiled with debug infos switched on,
and that backtracing explicitly is enabled by importing
tango.core.tools.TraceException.
Of course Phobos can use the Tango BSD implementation since Phobos switched to
Boost license, but it shows that it's very possible. I wish the Phobos team
good luck duplication the functionality.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 22 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
faithful <aercjknjw yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aercjknjw yahoo.com
What annoys the heck out of me are the Tango fanboy faggots advertising their
viral library in every possible place.
There are good reasons why D 2.0 was born. The Boost license is good for larger
companies like Facebook because they simply refuse to give any attribution to
anyone in internal NDA projects. Doubting the excellence of Suckerberg is bad
for your Linkedin reputation when applying for a job. How would D succeed
without good attitude toward companies?
Another reason are OOP crazy design of Tango and politically inflammable secret
society style they use. The Phobos developer situation is much better. If the
rulers like your Boost inspired code, you get a developer status.
This is all OT, sorry * 1000.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 23 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Johannes Pfau <johannespfau gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |johannespfau gmail.com
PDT ---
Jonathan M Davis
You need to add "-L--export-dynamic" to the compiler flags, maybe adding it to
dmd.conf is the best idea. This gives stack traces with mangled names. Sean
said somewhere in the newsgroup that he's working on demangling stack traces,
but druntime can't use phobos code, so he has to rewrite the demangling code.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 23 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- Okay, demangling added for Linux and OSX. I'll try to make sure that -L--export-dynamic is added to dmd.conf on Linux for the next release. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 09 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 Note that ddmd has custom working stack trace code for windoze. Maybe this could help in some way. http://dsource.org/projects/ddmd -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 16 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
vano <ivan.melnychuk+d gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ivan.melnychuk+d gmail.com
---
There's two big things left on my list for stacktraces (at least on linux) that
need to be done:
1) the default dmd.conf needs to have -L--export-dynamic in it
2) the strings from backtrace_symbols need to be demangled
Any collapsing of recursion is a distant second in my opinion.
Obviously, for those that use windows, traces on windows would probably go
So true! The lack of backtrace (stacktrace) on Windows is so frustrating. I
really hope that with this bug having quite few votes Sean would implement it
in the near future.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 02 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Benjamin Thaut <code benjamin-thaut.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |code benjamin-thaut.de
06:39:34 PDT ---
For a win32 stacktrace (XP+) you might check my project on this:
http://3d.benjamin-thaut.de/?p=15
Kind Regards
Benjamin Thaut
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 07 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 08:22:14 PST ---Okay, demangling added for Linux and OSX. I'll try to make sure that -L--export-dynamic is added to dmd.conf on Linux for the next release.Wouldn't it be better, if it will be added by compiler itself when command line have any of -g, -gc, -debug, -cov, -profile? BTW. after adding -L--export-dynamic under Linux stacktrace display works almost perfectly. Example: $D/dmt> ./dmt s.dt std.stream.OpenException: Cannot open or create file 's.dt' ---------------- ./dmt(std std.stream.StreamException.__ctor(immutable(char)[])) [0x809ccf9] ./dmt(std std.stream.StreamFileException.__ctor(immutable(char)[])) [0x80a0507] ./dmt(std std.stream.OpenException.__ctor(immutable(char)[])) [0x80a0527] ./dmt(_D3std6stream4File4openMFAyaE3std6stream8FileModeZv+0xe5) [0x80a06d9] ./dmt(_D3std6stream4File6__ctorMFAyaE3std6stream8FileModeZC3std6stream4File+0x25) [0x80a05ed] ./dmt(_D3std6stream12BufferedFile6__ctorMFAyaE3std6stream8FileModekZC3std6stream12BufferedFile+0x28) [0x80a0c9c] ./dmt(bool dmt.Convert(immutable(char)[], immutable(char)[])) [0x808a7e9] ./dmt(_Dmain+0x1ef) [0x808b323] ./dmt(extern (C) int rt.dmain2.main(int, char**)) [0x8091279] ./dmt(extern (C) int rt.dmain2.main(int, char**)) [0x80911cf] ./dmt(extern (C) int rt.dmain2.main(int, char**)) [0x80912bf] ./dmt(extern (C) int rt.dmain2.main(int, char**)) [0x80911cf] ./dmt(main+0xa7) [0x8091177] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xb7630c76] ./dmt() [0x808a431] $ I had everything compiled with -gc -L--export-dynamic including druntime and phobos. For some reasons it still do not demangle some symbols. It happens both in when compiling phobos/druntime with -release and without it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Nov 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PST ---For a win32 stacktrace (XP+) you might check my project on this: http://3d.benjamin-thaut.de/?p=15Thanks! I've noticed that the code doesn't have a Boost-compatible copyright. Would you be averse to changing this so some derivative could be used in druntime? I also found this in the MSDN docs: "All DbgHelp functions, such as this one, are single threaded. Therefore, calls from more than one thread to this function will likely result in unexpected behavior or memory corruption. To avoid this, you must synchronize all concurrent calls from more than one thread to this function." http://msdn.microsoft.com/en-us/library/ms681327(v=vs.85).aspx I guess that means that the stack trace generation on Windows will have to be wrapped in a synchronized block. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 20 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 What's the status of Windows stack trace integration? Note that Benjamin's code needs to be updated by adding an opApply version with index to class Callstack. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 15 2011
<d-bugmail puremagic.com> wrote:http://d.puremagic.com/issues/show_bug.cgi?id=1001 What's the status of Windows stack trace integration? Note that Benjamin's code needs to be updated by adding an opApply version with index to class Callstack.Next release.
Mar 16 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 00:56:13 PDT ---What's the status of Windows stack trace integration? Note that Benjamin's code needs to be updated by adding an opApply version with index to class Callstack.I just updated the code on my blog, the opApply issue is fixed and it is also under a new licence which hopefully removes the problem of adding it to phobos. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 23 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- The changes are in. I worked from the original implementation, since I'd already taken care of the opApply issue and such. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 24 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Matt Peterson <revcompgeek gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |revcompgeek gmail.com
PDT ---
I'm not sure what the problem is, but this isn't working for me on Linux 64bit.
I get the "----------------" line that signifies the start of the stack trace
but nothing shows up. I've been tinkering around with the druntime library a
little bit but I can't seem to get any useful information, I'm not sure where
to check anyway.
What can I do to help resolve this? Would it be useful to test the latest
version from github?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 20 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- The code for this is in core/runtime. If you're using a custom dmd.conf, the problem may be that you're missing an -L--export-dynamic. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 23 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT ---The code for this is in core/runtime. If you're using a custom dmd.conf, the problem may be that you're missing an -L--export-dynamic.I'm not using a custom dmd.conf and that switch is there. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 23 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- I haven't been seeing the stack traces with 64-bit either. I don't even get the addresses (which is what you get if you don't have -L--export-dynamic). I'm seeing the same behavior as Matt. It works fine on my 32-bit machine, but on my 64-bit machine where I'm using pure 64-bit D (dmd, druntime, and Phobos are all 64-bit), the stack traces are always empty. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 23 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- I just tested building with -m32 and that works, although the symbols are still mangled. With -m64 I don't get any lines in the stack trace at all. In fact, I only see one line of ---------. I'm not not getting the one there should be at the end. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 23 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- Nevermind, I am seeing the second line of dashes, I was just getting confused at the difference between Throwable.toString and the way the runtime prints it out when it's unhandled. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 24 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 To be closed? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 03 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- Maybe. I think there's a couple outstanding issues that could be separated: 1) common look and feel of the stack trace output for all platforms. Right now every platform produces different traces. 2) there's a report that the top frame is missing from one platform or another (from you I think) 3) 64 traces doesn't seem to work at all. I need to re-check, but I think freebsd/* might also be broken. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 03 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 Any news regarding x64 traces? They still don't work at all. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 09 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001
No, stack trace is still empty.
btw, while trying to get an exception I noticed that neither of the following
is caught:
void main()
{
int b = 0;
int a = 5/b;
}
--- killed by signal 8
void main()
{
int* a;
int b = *a;
}
--- killed by signal 11
Is this ok?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 18 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- Those don't generate exceptions. They generate signals, which are completely different. And it's the OS which generates them, I believe. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 18 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 I do know about signals, I just wasn't sure if druntime is supposed to catch (some of) them. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 18 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001Those don't generate exceptions. They generate signals, which are completely different. And it's the OS which generates them, I believe.If the compiler adds tests (in nonrelease mode only, or maybe only in nonrelease -debug mode only) before those operations, then they too are able to produce a stack trace. Stack traces are handy. So is this a new feature worth asking for? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 18 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001Yeah, Linux sends a signal when you have a memory violation like accessing a null pointer, and I've had success with creating a signal handler for SIGSEGV and throwing an exception manually. It's actually really easy, and it's much faster than having null pointer checks.And Windows creates an exception, which does appear in the stack trace. The behaviour is very strongly OS-dependent. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 18 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 PDT --- If you want exceptions for these events on Posix, create a signal handler and throw one. On some OSes it will work and on others it won't. Assuming you're targeting a platform where it works though, doing so might be a net win. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 19 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001 Seems like stack traces are finally supported on x64. Any plans to add line numbers to them? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 01 2011
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Vladimir Panteleev <thecybershadow gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |thecybershadow gmail.com
09:33:29 PST ---
Seems like stack traces are finally supported on x64. Any plans to add line
numbers to them?
Looks like that would be difficult without a dependency on binutils.
Even then, binutils is GPL. I'm not sure how GPL works with regards to weak
(optional) dependencies?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 06 2012
http://d.puremagic.com/issues/show_bug.cgi?id=1001 How much work is left to do before closing down this issue as fixed? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 24 2012
http://d.puremagic.com/issues/show_bug.cgi?id=1001 06:43:58 PDT --- I believe two matters remain: 1) Getting stack traces on unhandled signals (or at least SIGSEGV). There is ongoing discussion in this pull request: https://github.com/D-Programming-Language/druntime/pull/187 2) Getting line numbers on POSIX. I don't think this goal is easily directly reachable. The corresponding library (binutils) that parses DWARF debug information and extracts line numbers in licensed under the GNU GPL, meaning that loading it dynamically and passing around data structures is out of the question (see http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins). However, the D distribution can include a small GPL-licensed program that can take an exception stack trace as stdin, and convert it to include line number information, similar to the addr2line utility. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 24 2012
http://d.puremagic.com/issues/show_bug.cgi?id=1001 06:48:44 PST --- For windows x86: 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: -------
Dec 23 2012
http://d.puremagic.com/issues/show_bug.cgi?id=1001
Jameson <beatgammit gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |beatgammit gmail.com
2) Getting line numbers on POSIX.
I don't think this goal is easily directly reachable. The corresponding library
(binutils) that parses DWARF debug information and extracts line numbers in
licensed under the GNU GPL, meaning that loading it dynamically and passing
around data structures is out of the question (see
http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins). However, the D
distribution can include a small GPL-licensed program that can take an
exception stack trace as stdin, and convert it to include line number
information, similar to the addr2line utility.
Would something like this work?
http://sourceforge.net/apps/trac/elftoolchain/
It's being developed for FreeBSD, so it's likely to work there and on Linux. I
don't know of the progress, but it seems to be slated for the FreeBSD 10
release:
https://wiki.freebsd.org/GPLinBase
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 23 2013