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

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

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

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

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

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

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

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

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

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