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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------