www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1001] New: print stack trace (in debug mode) when program die

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001





------- Comment #1 from tknott gmail.com  2007-02-23 00:07 -------
The Flectioned runtime reflection library (http://flectioned.kuehne.cn/) can
provide this, though language support would be welcome.


-- 
Feb 22 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001


Hoenir <mrmocool gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrmocool gmx.de


--- Comment #2 from Hoenir <mrmocool gmx.de> 2010-01-17 17:58:15 PST ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001


Sean Kelly <sean invisibleduck.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED


--- Comment #3 from Sean Kelly <sean invisibleduck.org> 2010-02-02 20:12:53 PST
---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001


BCS <shro8822 vandals.uidaho.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |shro8822 vandals.uidaho.edu


--- Comment #4 from BCS <shro8822 vandals.uidaho.edu> 2010-02-02 22:40:41 PST
---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001


Brad Roberts <braddr puremagic.com> changed:

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


--- Comment #5 from Brad Roberts <braddr puremagic.com> 2010-02-02 22:52:04 PST
---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #6 from BCS <shro8822 vandals.uidaho.edu> 2010-02-02 23:44:41 PST
---
(In reply to comment #5)
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #7 from Brad Roberts <braddr puremagic.com> 2010-02-03 01:19:34 PST
---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #8 from Sean Kelly <sean invisibleduck.org> 2010-02-04 16:38:11 PST
---
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__)
#   include <ucontext.h>
#elif defined(__APPLE__)
#   include <execinfo.h>

    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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #9 from Sean Kelly <sean invisibleduck.org> 2010-02-04 16:40:01 PST
---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--- Comment #10 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2010-02-04
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #11 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2010-02-04
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #12 from Sean Kelly <sean invisibleduck.org> 2010-02-04 16:50:35
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #13 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2010-02-04
17:19:01 PST ---
(In reply to comment #12)
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #14 from Sean Kelly <sean invisibleduck.org> 2010-02-04 20:13:33
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #15 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2010-02-05
05:28:30 PST ---
(In reply to comment #14)
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #16 from Sean Kelly <sean invisibleduck.org> 2010-05-05 15:03:24
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #17 from Brad Roberts <braddr puremagic.com> 2010-05-05 19:00:08
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #18 from Sean Kelly <sean invisibleduck.org> 2010-05-06 10:15:57
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #19 from Brad Roberts <braddr puremagic.com> 2010-05-25 00:15:31
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #20 from Sean Kelly <sean invisibleduck.org> 2010-05-25 15:18:01
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #21 from Brad Roberts <braddr puremagic.com> 2010-05-25 15:49:27
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc


--- Comment #22 from bearophile_hugs eml.cc 2010-05-26 04:25:20 PDT ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au


--- Comment #23 from Don <clugdbug yahoo.com.au> 2010-05-26 05:41:33 PDT ---
(In reply to comment #22)

 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #24 from Brad Roberts <braddr puremagic.com> 2010-05-29 00:42:56
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
above #1 in priority -- but I'm not in that set. :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #25 from Brad Roberts <braddr puremagic.com> 2010-05-31 14:58:39
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001


Jonathan M Davis <jmdavisProg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmail.com


--- Comment #26 from Jonathan M Davis <jmdavisProg gmail.com> 2010-08-22
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001


nfxjfg gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nfxjfg gmail.com


--- Comment #27 from nfxjfg gmail.com 2010-08-22 23:19:26 PDT ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001


faithful <aercjknjw yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aercjknjw yahoo.com


--- Comment #28 from faithful <aercjknjw yahoo.com> 2010-08-23 04:32:19 PDT ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001


Johannes Pfau <johannespfau gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johannespfau gmail.com


--- Comment #29 from Johannes Pfau <johannespfau gmail.com> 2010-08-23 06:33:45
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #30 from Sean Kelly <sean invisibleduck.org> 2010-09-09 13:32:47
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #31 from Trass3r <mrmocool gmx.de> 2010-09-16 05:07:27 PDT ---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--- Comment #32 from vano <ivan.melnychuk+d gmail.com> 2010-10-02 10:18:36 PDT
---
(In reply to comment #24)
 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
 above #1 in priority -- but I'm not in that set. :)

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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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


--- Comment #33 from Benjamin Thaut <code benjamin-thaut.de> 2010-10-07
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #34 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2010-11-24
08:22:14 PST ---
(In reply to comment #30)
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #35 from Sean Kelly <sean invisibleduck.org> 2011-01-20 15:40:41
PST ---
(In reply to comment #33)
 For a win32 stacktrace (XP+) you might check my project on this:
 
 http://3d.benjamin-thaut.de/?p=15

Thanks! 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
prev sibling next sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #36 from Trass3r <mrmocool gmx.de> 2011-03-15 05:10:07 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 15 2011
parent Sean Kelly <sean invisibleduck.org> writes:
<d-bugmail puremagic.com> wrote:
 http://d.puremagic.com/issues/show_bug.cgi?id=1001
 
 
 
 --- Comment #36 from Trass3r <mrmocool gmx.de> 2011-03-15 05:10:07 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.

Next release.
Mar 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #37 from Benjamin Thaut <code benjamin-thaut.de> 2011-03-23
00:56:13 PDT ---
(In reply to comment #36)
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #38 from Sean Kelly <sean invisibleduck.org> 2011-03-24 12:10:44
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001


Matt Peterson <revcompgeek gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |revcompgeek gmail.com


--- Comment #39 from Matt Peterson <revcompgeek gmail.com> 2011-05-20 20:53:12
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #40 from Sean Kelly <sean invisibleduck.org> 2011-05-23 15:27:35
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #41 from Matt Peterson <revcompgeek gmail.com> 2011-05-23 15:41:50
PDT ---
(In reply to comment #40)
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #42 from Jonathan M Davis <jmdavisProg gmx.com> 2011-05-23 17:44:47
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #43 from Matt Peterson <revcompgeek gmail.com> 2011-05-23 21:05:38
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
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #44 from Matt Peterson <revcompgeek gmail.com> 2011-05-24 08:00:56
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