www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A working backtrace for linux

reply David Bryant <bagnose gmail.com> writes:
Hi all,

I've been using D under Ubuntu for some time and the kinds of backtraces 
I get when assertion fails look like this:

core.exception.AssertError doodle.dia.standard_tools(71): Assertion failure
----------------
./bin/doodler() [0x8102086]
./bin/doodler() [0x804e38f]
./bin/doodler() [0x81022b1]
./bin/doodler() [0x81021d9]
./bin/doodler() [0x8102188]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x289bd6]
./bin/doodler() [0x8049a01]

And for segment faults I don't get a stack trace at all.

I am interested in knowing if this is the case for other users and if 
so, what is being done about it in druntime?

I've attached my own implementation of backtrace that I find useful. It 
is quick and dirty, but it works. It gives an output like the following 
when exceptions are thrown and segmentation faults triggered:

core.exception.AssertError doodle.dia.standard_tools(71): Assertion failure
----------------
[0x0810bbf8] onAssertError
[0x081022c6] _d_assertm
[0x0804e43f] void doodle.dia.standard_tools.__assert(int)
[0x0804dfb8] bool doodle.dia.standard_tools.ZoomTool.handle_scroll(class 
doodle.dia.icanvas.Viewport, const(class doodle.tk.events.ScrollEvent))
[0x0804e951] bool doodle.dia.tool_layer.ToolLayer.handle_scroll(class 
doodle.dia.icanvas.Viewport, const(class doodle.tk.events.ScrollEvent))
[0x0804b607] bool doodle.gtk.canvas.Canvas.on_scroll(struct 
gtkc.gdktypes.GdkEventScroll*, class gtk.Widget.Widget)
[0x080672c5] extern (C) int gtk.Widget.Widget.callBackScroll(struct 
gtkc.gtktypes.GtkWidget*, struct gtkc.gdktypes.GdkEventScroll*, class 
gtk.Widget.Widget)
[0x08062155] void gtk.Main.Main.run()
[0x08049e7b] _Dmain
[0x08102594] extern (C) int rt.dmain2.main(int, char**) . void runMain()
[0x081024f9] extern (C) int rt.dmain2.main(int, char**) . void 
tryExec(void delegate())

Using it couldn't be easier, just import the module and link the object.

Regards,
Dave
Aug 02 2010
next sibling parent reply Trass3r <un known.com> writes:
Which reminds me that there are still no traces for Windoze, even though  
Tango has been providing for quite some time IIRC.
Aug 03 2010
parent reply Sean Kelly <sean invisibleduck.org> writes:
Trass3r Wrote:


 Which reminds me that there are still no traces for Windoze, even though  
 Tango has been providing for quite some time IIRC.


Then perhaps the person who wrote the Tango Win32 backtrace will submit it to
Phobos :-)  I've been busy with other things recently, but Win32 backtrace is
coming.  It's just more work than the 30 minutes it took me to do the Linux/OSX
one (which admittedly needs some work as well).
Aug 03 2010
next sibling parent Trass3r <un known.com> writes:
 Then perhaps the person who wrote the Tango Win32 backtrace will submit  
 it to Phobos :-)


So far they haven't shown much interest in D2 ;)
Aug 03 2010
prev sibling parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
On 04/08/10 05:30, Sean Kelly wrote:

 Trass3r Wrote:

    

 Which reminds me that there are still no traces for Windoze, even though
 Tango has been providing for quite some time IIRC.
      


 Then perhaps the person who wrote the Tango Win32 backtrace will submit it to
Phobos :-)  I've been busy with other things recently, but Win32 backtrace is
coming.  It's just more work than the 30 minutes it took me to do the Linux/OSX
one (which admittedly needs some work as well).
    


Sean, is there any chance of you rolling some of the good stuff in this 
code into druntime?

In particular, it would be very nice to get symbol names in a stacktrace 
rather than a bunch of addresses, and even nicer to get a stacktrace on 
a SIGSEGV.

-- 
Graham St Jack
Aug 03 2010
parent reply Sean Kelly <sean invisibleduck.org> writes:
Graham St Jack Wrote:

 Sean, is there any chance of you rolling some of the good stuff in this 
 code into druntime?
 
 In particular, it would be very nice to get symbol names in a stacktrace 
 rather than a bunch of addresses, and even nicer to get a stacktrace on 
 a SIGSEGV.


You can get the symbol names by adding -L--export-dynamic to your DFLAGS in
dmd.conf.  That option is on by default on OSX and I didn't realize it was
different on Linux.  I'll sort out demangling as well, it's just a bit more
work.  I like the stack trace code provided, but it uses a lot of modules that
aren't available to druntime so it would be difficult to use directly.
Aug 03 2010
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 8/3/2010 8:09 PM, Sean Kelly wrote:

 Graham St Jack Wrote:

 Sean, is there any chance of you rolling some of the good stuff in this 
 code into druntime?

 In particular, it would be very nice to get symbol names in a stacktrace 
 rather than a bunch of addresses, and even nicer to get a stacktrace on 
 a SIGSEGV.


 
 You can get the symbol names by adding -L--export-dynamic to your DFLAGS in
dmd.conf.  That option is on by default on OSX and I didn't realize it was
different on Linux.  I'll sort out demangling as well, it's just a bit more
work.  I like the stack trace code provided, but it uses a lot of modules that
aren't available to druntime so it would be difficult to use directly.


see also my notes in bug 1001, the one all about this topic.
Aug 03 2010
parent Graham St Jack <Graham.StJack internode.on.net> writes:
On 04/08/10 12:47, Brad Roberts wrote:

 On 8/3/2010 8:09 PM, Sean Kelly wrote:
    

 Graham St Jack Wrote:
      

 Sean, is there any chance of you rolling some of the good stuff in this
 code into druntime?

 In particular, it would be very nice to get symbol names in a stacktrace
 rather than a bunch of addresses, and even nicer to get a stacktrace on
 a SIGSEGV.
        


 You can get the symbol names by adding -L--export-dynamic to your DFLAGS in
dmd.conf.  That option is on by default on OSX and I didn't realize it was
different on Linux.  I'll sort out demangling as well, it's just a bit more
work.  I like the stack trace code provided, but it uses a lot of modules that
aren't available to druntime so it would be difficult to use directly.
      


 see also my notes in bug 1001, the one all about this topic.
    


Thanks for the heads-up - I will keep a closer eye on the bug-list in 
future. Its great to see all the action going on under the hood.

-- 
Graham St Jack
Aug 03 2010
prev sibling parent reply David Bryant <bagnose gmail.com> writes:
Ok,

I've added -L--export-dynamic to dmd.conf and done a copy/modify of 
DefaultTraceInfo from runtime.d to include demangling and catch certain 
signals. My backtraces now look gorgeous under Linux.

I've attached the source for the updated module.

Thanks,
Dave

On 04/08/10 12:39, Sean Kelly wrote:

 Graham St Jack Wrote:

 Sean, is there any chance of you rolling some of the good stuff in this
 code into druntime?

 In particular, it would be very nice to get symbol names in a stacktrace
 rather than a bunch of addresses, and even nicer to get a stacktrace on
 a SIGSEGV.


 You can get the symbol names by adding -L--export-dynamic to your DFLAGS in
dmd.conf.  That option is on by default on OSX and I didn't realize it was
different on Linux.  I'll sort out demangling as well, it's just a bit more
work.  I like the stack trace code provided, but it uses a lot of modules that
aren't available to druntime so it would be difficult to use directly.
Aug 03 2010
next sibling parent reply Johannes Pfau <spam example.com> writes:
On 04.08.2010 07:26, David Bryant wrote:

 Ok,
 
 I've added -L--export-dynamic to dmd.conf and done a copy/modify of
 DefaultTraceInfo from runtime.d to include demangling and catch certain
 signals. My backtraces now look gorgeous under Linux.
 
 I've attached the source for the updated module.
 
 Thanks,
 Dave
 


Nice work, but one question regarding signal handling:
You throw an Error directly in the signal handler, isn't
this quite dangerous? See for example
http://en.wikipedia.org/wiki/Signal_(computing)#Risks
(That's all theory though: in practice signal handling implementations
are usually more robust.)


-- 
Johannes Pfau
Aug 04 2010
parent Sean Kelly <sean invisibleduck.org> writes:
Johannes Pfau <spam example.com> wrote:

 On 04.08.2010 07:26, David Bryant wrote:

 Ok,
 
 I've added -L--export-dynamic to dmd.conf and done a copy/modify of
 DefaultTraceInfo from runtime.d to include demangling and catch
 certain
 signals. My backtraces now look gorgeous under Linux.
 
 I've attached the source for the updated module.
 
 Thanks,
 Dave
 


 
 Nice work, but one question regarding signal handling:
 You throw an Error directly in the signal handler, isn't
 this quite dangerous? See for example
 http://en.wikipedia.org/wiki/Signal_(computing)#Risks
 (That's all theory though: in practice signal handling implementations
 are usually more robust.)
 


This actually came up during Andrei's talk at Google. Throwing
exceptions from signal handlers is illegal insofar as Posix docs are
concerned, so this feature won't be in druntime. It does actually work
on some platforms though, so it's a good thing to test and add if you
want this feature.
Aug 04 2010
prev sibling parent Rory Mcguire <rjmcguire gm_no_ail.com> writes:
Thanks!!

The code at the start of this thread didn't work at all for me but what 
you've done works.


David Bryant wrote:


 Ok,
 
 I've added -L--export-dynamic to dmd.conf and done a copy/modify of
 DefaultTraceInfo from runtime.d to include demangling and catch certain
 signals. My backtraces now look gorgeous under Linux.
 
 I've attached the source for the updated module.
 
 Thanks,
 Dave
 
 On 04/08/10 12:39, Sean Kelly wrote:

 Graham St Jack Wrote:

 Sean, is there any chance of you rolling some of the good stuff in this
 code into druntime?

 In particular, it would be very nice to get symbol names in a stacktrace
 rather than a bunch of addresses, and even nicer to get a stacktrace on
 a SIGSEGV.


 You can get the symbol names by adding -L--export-dynamic to your DFLAGS
 in dmd.conf.  That option is on by default on OSX and I didn't realize it
 was different on Linux.  I'll sort out demangling as well, it's just a
 bit more work.  I like the stack trace code provided, but it uses a lot
 of modules that aren't available to druntime so it would be difficult to
 use directly.
Aug 04 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
David Bryant, el  3 de agosto a las 14:47 me escribiste:

 Hi all,
 
 I've been using D under Ubuntu for some time and the kinds of
 backtraces I get when assertion fails look like this:
 
 core.exception.AssertError doodle.dia.standard_tools(71): Assertion failure
 ----------------
 ./bin/doodler() [0x8102086]
 ./bin/doodler() [0x804e38f]
 ./bin/doodler() [0x81022b1]
 ./bin/doodler() [0x81021d9]
 ./bin/doodler() [0x8102188]
 /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x289bd6]
 ./bin/doodler() [0x8049a01]
 
 And for segment faults I don't get a stack trace at all.
 
 I am interested in knowing if this is the case for other users and
 if so, what is being done about it in druntime?
 
 I've attached my own implementation of backtrace that I find useful.
 It is quick and dirty, but it works. It gives an output like the
 following when exceptions are thrown and segmentation faults
 triggered:
 
 core.exception.AssertError doodle.dia.standard_tools(71): Assertion failure
 ----------------
 [0x0810bbf8] onAssertError
 [0x081022c6] _d_assertm
 [0x0804e43f] void doodle.dia.standard_tools.__assert(int)
 [0x0804dfb8] bool
 doodle.dia.standard_tools.ZoomTool.handle_scroll(class
 doodle.dia.icanvas.Viewport, const(class
 doodle.tk.events.ScrollEvent))
 [0x0804e951] bool
 doodle.dia.tool_layer.ToolLayer.handle_scroll(class
 doodle.dia.icanvas.Viewport, const(class
 doodle.tk.events.ScrollEvent))
 [0x0804b607] bool doodle.gtk.canvas.Canvas.on_scroll(struct
 gtkc.gdktypes.GdkEventScroll*, class gtk.Widget.Widget)
 [0x080672c5] extern (C) int gtk.Widget.Widget.callBackScroll(struct
 gtkc.gtktypes.GtkWidget*, struct gtkc.gdktypes.GdkEventScroll*,
 class gtk.Widget.Widget)
 [0x08062155] void gtk.Main.Main.run()
 [0x08049e7b] _Dmain
 [0x08102594] extern (C) int rt.dmain2.main(int, char**) . void runMain()
 [0x081024f9] extern (C) int rt.dmain2.main(int, char**) . void
 tryExec(void delegate())
 
 Using it couldn't be easier, just import the module and link the object.


You might be interested in this thread:
http://thread.gmane.org/gmane.comp.lang.d.phobos/1468


-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Un camión lleno de amigos, míos.
Cada uno dando vueltas, en su cabeza.
Mientras yo, sufro la picadura de mi propia abeja.
Aug 03 2010
prev sibling parent reply Kagamin <spam here.lot> writes:
Leandro Lucarella Wrote:


 You might be interested in this thread:
 http://thread.gmane.org/gmane.comp.lang.d.phobos/1468
 


What's a druntime list?
Aug 03 2010
parent Leandro Lucarella <luca llucax.com.ar> writes:
Kagamin, el  3 de agosto a las 22:54 me escribiste:

 Leandro Lucarella Wrote:
 

 You might be interested in this thread:
 http://thread.gmane.org/gmane.comp.lang.d.phobos/1468
 


 What's a druntime list?


A mailing list[1] where the topic is Druntime[2] perhaps?

[1] http://lists.puremagic.com/mailman/listinfo/d-runtime
[2] http://www.dsource.org/projects/druntime/

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
La esperanza es una amiga que nos presta la ilusión.
Aug 04 2010