[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1001

RazvanN  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--- Comment #83 from RazvanN  ---
Closing this based on previous comments.

--

[Issue 1001] print stack trace (in debug mode) when program die

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1001

Andrei Alexandrescu  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|alexandru.razva...@gmail.co
   ||m

--

[Issue 1001] print stack trace (in debug mode) when program die

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1001

Andrei Alexandrescu  changed:

   What|Removed |Added

   Assignee|lucia.mcojoc...@gmail.com   |nob...@puremagic.com

--

[Issue 1001] print stack trace (in debug mode) when program die

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1001

--- Comment #82 from Brad Roberts  ---
I think what's left here is for someone, probably Lucia, to survey the current
state of all the platforms and file a few smaller bug reports that cover what
doesn't work well.  One of them is probably a "cleanup the actual output to be
consistent across platforms".  This specific bug report has likely outlived
it's usefulness.

--

[Issue 1001] print stack trace (in debug mode) when program die

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1001

--- Comment #81 from Vladimir Panteleev  ---
Worth noting that I think something changed within the 2 years since the last
message from 2014, since we now have stack traces with line numbers on Linux.

--

[Issue 1001] print stack trace (in debug mode) when program die

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1001

Andrei Alexandrescu  changed:

   What|Removed |Added

   Assignee|s...@invisibleduck.org  |lucia.mcojoc...@gmail.com

--

[Issue 1001] print stack trace (in debug mode) when program die

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1001

Andrei Alexandrescu  changed:

   What|Removed |Added

   Keywords||bootcamp

--

[Issue 1001] print stack trace (in debug mode) when program die

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1001

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #80 from Andrei Alexandrescu  ---
Maybe Lucia can take a look.

--

[Issue 1001] print stack trace (in debug mode) when program die

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=1001

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|2.020   |D2

--

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #75 from Vladimir Panteleev thecybersha...@gmail.com 2014-02-15 
22:17:15 EET ---
(In reply to comment #63)
 So we have stack traces on all platforms by now, can I close the bug?

What about line numbers? I think we only have them on Win64.

 Regarding DWARF processing, it shouldn't be too hard.

DWARF uses a weird state machine for efficient representation of file/line
information. Doable but not trivial.

 But we could also dynamically load libdw.so from elfutils if it's installed
 similarly to how we load dbghelp.dll on Windows.

It's GPL just like binutils. IANAL, but I'm not sure about dynamically loading
GPL libs. I know the GPL forbids redistribution of any programs that include
the library... Doesn't that mean that it would make it impossible for e.g.
Linux distributions to distribute non-GPL D software together with the library?

 https://github.com/bombela/backward-cpp

This seems to only support binutils and elfutils, both of which are GPL.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||andrej.mitrov...@gmail.com


--- Comment #76 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-02-15 
12:23:39 PST ---
(In reply to comment #64)
 on Windows 64 bit a executable still crashes silently when a access violation
 occures. At least with 2.064.2
 
 Code used to test:
 import core.stdc.stdio;
 
 void test()
 {
   int* i;
   *i = 5;
 }
 
 void main(string[] args)
 {
 test();
 printf(done\n);
 }

I can't reproduce this on Win7 x64 with 2.064. Here's the results for me:

$ dmd
 DMD32 D Compiler v2.064

$ dmd -run test.d
object.Error: Access Violation

0x00402012 in __xc_a
0x004022FF in __xi_a
0x00402217 in __xc_z
0x00402047 in __xc_a
0x75CC3677 in BaseThreadInitThunk
0x77859D72 in __RtlUserThreadStart
0x77859D45 in _RtlUserThreadStart


$ dmd -g -run test.d
object.Error: Access Violation

0x00402019 in void test.test() at C:\dev\code\d_code\test.d(6)
0x0040202C in _Dmain at C:\dev\code\d_code\test.d(12)
0x0040233C in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll().void __lambda1()
0x0040230F in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x00402227 in _d_run_main
0x00402054 in main
0x004140A9 in mainCRTStartup
0x75CC3677 in BaseThreadInitThunk
0x77859D72 in __RtlUserThreadStart
0x77859D45 in _RtlUserThreadStart


-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #78 from Vladimir Panteleev thecybersha...@gmail.com 2014-02-15 
22:31:49 EET ---
(In reply to comment #76)
 I can't reproduce this on Win7 x64 with 2.064. Here's the results for me:

The problem applies to 64-bit programs. I can reproduce it with -m64.

(In reply to comment #75)
 It's GPL just like binutils. IANAL, but I'm not sure about dynamically loading
 GPL libs. I know the GPL forbids redistribution of any programs that include
 the library... Doesn't that mean that it would make it impossible for e.g.
 Linux distributions to distribute non-GPL D software together with the 
 library?

Just found this:
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL

Quoting:
 Q: If a library is released under the GPL (not the LGPL), does that mean that 
 any software which uses it has to be under the GPL or a GPL-compatible 
 license?
 
 A: Yes, because the software as it is actually run includes the library.

So I guess that gives us a definitive answer. We CANNOT use binutils or
elfutils, so libdw and libbfd are out of the question. From the discussed
options, that leaves FreeBSD's Elftoolchain, integrating with addr2line, or our
own DWARF/ELF parser.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #77 from Benjamin Thaut c...@benjamin-thaut.de 2014-02-15 
12:31:09 PST ---
@Andrej Mitrovic
You forgott the -m64 switch in your test. You are testing 32-bit binaries. The
problem is not the 64 bit operating system it is the 64-bit executable, as 64
bit executables do not implement SEH.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #79 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-02-15 
12:50:07 PST ---
(In reply to comment #77)
 @Andrej Mitrovic
 You forgott the -m64 switch in your test. You are testing 32-bit binaries.

My bad. It's a huge thread and I didn't notice this. I can now confirm your
test results with -m64.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #72 from Vladimir Panteleev thecybersha...@gmail.com 2014-01-11 
14:06:23 EET ---
(In reply to comment #71)
 It's simply that the compiler cannot handle cleanup when every instruction
 could throw. In case an asynchronous exception happens in the middle of some
 statement your program is immediately in an invalid state. Continuing could
 deadlock or corrupt data, much worse than a crash.

OK... so the problem is basically that we call destructors / finally blocks /
scope(exit) blocks when Errors are thrown, and those may behave in a bad way
since the program was in an indeterminate state? I imagine that it's the same
for signals on POSIX? In that case, I suppose we could handle both in the same
way: immediately print a stack trace and exit, but still provide a mechanism
for the user to customize handling of such conditions.

I recall a discussion regarding whether thrown Errors should call finalizers on
the stack, but I suppose it's not really clear-cut.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #73 from Martin Nowak c...@dawg.eu 2014-01-11 10:53:13 PST ---
(In reply to comment #72)
 (In reply to comment #71)
 OK... so the problem is basically that we call destructors / finally blocks /
 scope(exit) blocks when Errors are thrown, and those may behave in a bad way
 since the program was in an indeterminate state? I imagine that it's the same
 for signals on POSIX? In that case, I suppose we could handle both in the same
 way: immediately print a stack trace and exit, but still provide a mechanism
 for the user to customize handling of such conditions.
 
 I recall a discussion regarding whether thrown Errors should call finalizers 
 on
 the stack, but I suppose it's not really clear-cut.

It's a bigger topic amd opinions vary. AFAIK Errors skip cleanup code, but it's
possible to catch Errors to perform minimal cleanup.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #74 from Jonathan M Davis jmdavisp...@gmx.com 2014-01-11 15:16:45 
PST ---
 It's a bigger topic amd opinions vary. AFAIK Errors skip cleanup code, but 
 it's possible to catch Errors to perform minimal cleanup.

According to Walter, there is no guarantee that any cleanup code is run when an
Error is thrown (though I'm not sure what the spec says on the matter).
However, some of the folks that believe that cleanup should be done on Errors
made it so that most cleanup code _is_ run when an Error is thrown. So, unless
something is changed, I believe that normally finally blocks, scope(exit),
scope(failure), and destructors will all be run when an Error is thrown. Where
they will get skipped is when an Error is thrown from a nothrow function, and
the cleanup code is outside the nothrow function, because the caller of the
nothrow function will assume that the nothrow function doesn't throw anything
and optimize based on that.

So, at this point, whether cleanup code is run on an Error depends on the code,
and at minimum, it will never be the case that cleanup code is always run on an
Error, because it won't be done for nothrow functions, or we lose the ability
to optimize it based on the fact that it won't throw an exception (which is one
its benefits). However, whether it will ever be changed such that cleanup code
is never run for Errors is an open question and a topic of hot debate.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #69 from Martin Nowak c...@dawg.eu 2014-01-07 02:20:21 PST ---
(In reply to comment #67) 
 Putting a null pointer dereference into try/catch does not catch it, so I 
 guess
 the root cause is that D exceptions are not integrated with Windows exceptions
 (through SEH or whatever mechanism is used on Win64).

Which is rather good, turning asynchronous SEH into normal Exceptions ws a bad
idea.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #70 from Vladimir Panteleev thecybersha...@gmail.com 2014-01-07 
12:24:10 EET ---
(In reply to comment #69)
 Which is rather good, turning asynchronous SEH into normal Exceptions ws a bad
 idea.

Could you elaborate why? I thought SEH was designed so that it would integrate
neatly with C++ exceptions.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #71 from Martin Nowak c...@dawg.eu 2014-01-07 02:55:12 PST ---
http://en.wikipedia.org/wiki/Exception_handling#Exception_synchronicity
It's simply that the compiler cannot handle cleanup when every instruction
could throw. In case an asynchronous exception happens in the middle of some
statement your program is immediately in an invalid state. Continuing could
deadlock or corrupt data, much worse than a crash.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #64 from Benjamin Thaut c...@benjamin-thaut.de 2014-01-06 
10:46:55 PST ---
on Windows 64 bit a executable still crashes silently when a access violation
occures. At least with 2.064.2

Code used to test:
import core.stdc.stdio;

void test()
{
  int* i;
  *i = 5;
}

void main(string[] args)
{
test();
printf(done\n);
}

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #66 from Vladimir Panteleev thecybersha...@gmail.com 2014-01-06 
22:22:50 EET ---
(In reply to comment #65)
 (In reply to comment #64)
  on Windows 64 bit a executable still crashes silently when a access 
  violation
  occures. At least with 2.064.2
 
 Fixed in git HEAD, see Issue 11865.

My bad, never mind. I get a WER dialog, though, so it's not silent?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #65 from Vladimir Panteleev thecybersha...@gmail.com 2014-01-06 
22:21:36 EET ---
(In reply to comment #64)
 on Windows 64 bit a executable still crashes silently when a access violation
 occures. At least with 2.064.2

Fixed in git HEAD, see Issue 11865.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #68 from Benjamin Thaut c...@benjamin-thaut.de 2014-01-06 
13:59:30 PST ---
Its not neccessary to implement windows SEH on 64-bit to support stack traces
on access violations (or other hardware exceptions). For now we could simply
use SetUnhandledExceptionFilter to handle such errors and then terminate the
program.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #67 from Vladimir Panteleev thecybersha...@gmail.com 2014-01-06 
23:55:44 EET ---
(In reply to comment #66)
 My bad, never mind. I get a WER dialog, though, so it's not silent?

Putting a null pointer dereference into try/catch does not catch it, so I guess
the root cause is that D exceptions are not integrated with Windows exceptions
(through SEH or whatever mechanism is used on Win64).

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=1001


Martin Nowak c...@dawg.eu changed:

   What|Removed |Added

 CC||c...@dawg.eu


--- Comment #63 from Martin Nowak c...@dawg.eu 2014-01-05 07:28:16 PST ---
So we have stack traces on all platforms by now, can I close the bug?

Regarding DWARF processing, it shouldn't be too hard.
But we could also dynamically load libdw.so from elfutils if it's installed
similarly to how we load dbghelp.dll on Windows.

http://forum.dlang.org/post/eahjyebbtjynlivij...@forum.dlang.org
https://github.com/bombela/backward-cpp

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


Jameson beatgam...@gmail.com changed:

   What|Removed |Added

 CC||beatgam...@gmail.com


--- Comment #62 from Jameson beatgam...@gmail.com 2013-05-23 01:34:51 PDT ---
(In reply to comment #60)
 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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #61 from Benjamin Thaut c...@benjamin-thaut.de 2012-12-23 
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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #59 from bearophile_h...@eml.cc 2012-07-24 06:00:03 PDT ---
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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #60 from Vladimir Panteleev thecybersha...@gmail.com 2012-07-24 
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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


Vladimir Panteleev thecybersha...@gmail.com changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com


--- Comment #58 from Vladimir Panteleev thecybersha...@gmail.com 2012-01-06 
09:33:29 PST ---
(In reply to comment #57)
 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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #57 from Trass3r mrmoc...@gmx.de 2011-12-01 17:25:12 PST ---
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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #56 from Sean Kelly s...@invisibleduck.org 2011-08-19 14:12:24 
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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #50 from Jonathan M Davis jmdavisp...@gmx.com 2011-08-18 13:20:46 
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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #51 from Trass3r mrmoc...@gmx.de 2011-08-18 13:31:02 PDT ---
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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #52 from bearophile_h...@eml.cc 2011-08-18 16:32:21 PDT ---
(In reply to comment #50)
 Those 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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #55 from Don clugd...@yahoo.com.au 2011-08-18 17:43:11 PDT ---
(In reply to comment #54)
 Yeah, 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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #45 from bearophile_h...@eml.cc 2011-07-03 12:55:16 PDT ---
To be closed?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #46 from Brad Roberts bra...@puremagic.com 2011-07-03 12:58:44 
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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #44 from Matt Peterson revcompg...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #40 from Sean Kelly s...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #41 from Matt Peterson revcompg...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #42 from Jonathan M Davis jmdavisp...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #43 from Matt Peterson revcompg...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


Matt Peterson revcompg...@gmail.com changed:

   What|Removed |Added

 CC||revcompg...@gmail.com


--- Comment #39 from Matt Peterson revcompg...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #38 from Sean Kelly s...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #37 from Benjamin Thaut c...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #36 from Trass3r mrmoc...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #35 from Sean Kelly s...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #34 from Witold Baryluk bary...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


Benjamin Thaut c...@benjamin-thaut.de changed:

   What|Removed |Added

 CC||c...@benjamin-thaut.de


--- Comment #33 from Benjamin Thaut c...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


vano ivan.melnychu...@gmail.com changed:

   What|Removed |Added

 CC||ivan.melnychu...@gmail.com


--- Comment #32 from vano ivan.melnychu...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #31 from Trass3r mrmoc...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #30 from Sean Kelly s...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


faithful aercjk...@yahoo.com changed:

   What|Removed |Added

 CC||aercjk...@yahoo.com


--- Comment #28 from faithful aercjk...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


Johannes Pfau johannesp...@gmail.com changed:

   What|Removed |Added

 CC||johannesp...@gmail.com


--- Comment #29 from Johannes Pfau johannesp...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


Jonathan M Davis jmdavisp...@gmail.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmail.com


--- Comment #26 from Jonathan M Davis jmdavisp...@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.except...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



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

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc


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

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au


--- Comment #23 from Don clugd...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



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

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #20 from Sean Kelly s...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #16 from Sean Kelly s...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



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

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #15 from Witold Baryluk bary...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #8 from Sean Kelly s...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


Witold Baryluk bary...@smp.if.uj.edu.pl changed:

   What|Removed |Added

 CC||bary...@smp.if.uj.edu.pl


--- Comment #10 from Witold Baryluk bary...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #11 from Witold Baryluk bary...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #13 from Witold Baryluk bary...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #14 from Sean Kelly s...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



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

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


Sean Kelly s...@invisibleduck.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED


--- Comment #3 from Sean Kelly s...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001


BCS shro8...@vandals.uidaho.edu changed:

   What|Removed |Added

 CC||shro8...@vandals.uidaho.edu


--- Comment #4 from BCS shro8...@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: ---

[Issue 1001] print stack trace (in debug mode) when program die

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=1001



--- Comment #6 from BCS shro8...@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: ---