pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] Re: Debugging Pan with gdb


From: Douglas Bollinger
Subject: Re: [Pan-users] Re: Debugging Pan with gdb
Date: Tue, 22 Aug 2006 18:15:54 -0400

On Tue, 22 Aug 2006 14:09:46 +0000 (UTC)
"Duncan" <address@hidden> wrote:

<snip>
> For x86 (and therefore for 32-bit x86 compatible code on amd64), omitting
> the frame-pointer DOES affect debugging, but ONLY on the libraries and
> executables where the flag is used.  (As a result it's not enabled by any
> -O level and must be invoked directly, again, gcc manpage.)
> 
> Assuming you are on x86, then, compiling pan without -fomit-frame-pointer
> should enable you to debug pan's own functions.  As soon as you hit the
> gtk or other libraries (glibc certainly, gcc's libstdc++ also since pan
> is now C++, other dependencies) compiled with -fomit-frame-pointer,
> however, you'll be in black-box territory -- you won't be able to trace
> into them.  Whether that kills debugging then depends on whether you can
> get enough info from what /is/ frame-pointered to be useful troubleshooting
> your particular problem, or not.
<snip>

Ok guys, I compiled gtk+ without the -fomit-frame-pointer flag.  Like you
said, it doesn't take very long.  I got some more information on the
backtrace:

(gdb) run
Starting program: /home/doug/pan-0.109/pan/gui/pan
[Thread debugging using libthread_db enabled]
[New Thread -1218734416 (LWP 9557)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218734416 (LWP 9557)]
0xb7e9ce0e in gtk_tree_view_set_fixed_height_mode ()
   from /usr/lib/libgtk-x11-2.0.so.0
(gdb) bt
#0  0xb7e9ce0e in gtk_tree_view_set_fixed_height_mode ()
   from /usr/lib/libgtk-x11-2.0.so.0
#1  0xb7ea9879 in gtk_tree_view_set_model () from /usr/lib/libgtk-x11-2.0.so.0
#2  0xb7dc6bf1 in gtk_marshal_VOID__UINT_STRING ()
   from /usr/lib/libgtk-x11-2.0.so.0
#3  0xb7b2eea9 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#4  0xbfac0068 in ?? ()
#5  0x00000000 in ?? ()

I'll add this to the bug report and see if it helps.

Thanks for the gdb info!

-- 
We can found no scientific discipline, nor a healthy profession on the
technical mistakes of the Department of Defense and IBM.
                -- Edsger Dijkstra




reply via email to

[Prev in Thread] Current Thread [Next in Thread]