Re: gtk-based sip client "locking up"

[Miguel Mendez <flynn energyhq es eu org>]

On Mon, 26 Apr 2004 14:09:12 +0300
Paul Pogonyshev <pogonyshev gmx net> wrote:

> Frank W. Miller wrote:
> > I'm writing a SIP client for Linux.  It has a command line interface
> >
> > currently but I've recently begun writing a GNOME GUI front-end.  I 
> > started with Glade and had reasonable success, i.e. I got it to
> > where is was making outbound calls with decent UI interactions.  I
> > then noticed a problem.  About half the time, when I started to make
> > a call, i.e. when I was sending the first few messages of the SIP
> > dialog, the GUI would "lock up" on me.  What this means is that I
> > have a couple of notebook tabs and some entry fields on each tab. 
> > There are also a couple of buttons.  Its pretty simple.  By lock up,
> > I mean that at some point the GUI just stops updating the various
> > widgets.  If I hit the tabs, it seems like its trying to switch
> > between them but I just get white rectangles and no labels.  The
> > program does not seem to recover from this.

You don't mention if your app is multi threaded. threaded apps are royal
PITA to debug :/

> 1) Valgrind.  It's not easy to find memory leaks in GTK+ code because
> GTK+
>    itself and especially X (it seems) both leak like mad, but reads of
>    uninitialized memory, writes to unallocated memory and such are
>    easily spottable with Valgrind.

Could you elaborate on that? I'm not 100% sure about X (although I have
my doubts, since I've had X running for 4-6 weeks with no problems), but
I don't think GTK+ leaks, at least not if used properly. About valgrind,
yes, that's a good option, albeit linux/x86 only. He could also use
Bruce Perens' Electric Fence and a number of other debugging malloc
libs. But I doubt it has anything to do with memory leaks, sounds more
like a mutex/semaphore problem, that is, if he's using threads.

> 2) Start your program under GDB, wait for it to lock up, hit Ctrl-C in
> the
>    terminal and study the backtrace.  Thus you can find in which
>    function it locks up.  Tracking _why_ it freezes can be more
>    difficult, though ;)

Or he can start the program from a shell and attach gdb to the running
process. Then see where the program is at that moment.

Cheers, 
-- 
        Miguel Mendez <flynn energyhq es eu org>
        http://www.energyhq.es.eu.org
        PGP Key: 0xDC8514F1