[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Debugging multiprecoss/multithreading library based application
From:       Dirk Stoecker <kde () dstoecker ! de>
Date:       2006-04-25 14:29:05
Message-ID: Pine.LNX.4.63.0604251623280.28038 () daneel ! site
[Download RAW message or body]

On Tue, 25 Apr 2006, Frans Englich wrote:

> > Using "ulimit -c xxxx" to create a core file fails due to KDE crash
> > manager.
> 
> All KDE applications have the switch --nocrashhandler. Perhaps it's useful.

Ah, very helpful. Good to know.

> > The error is based on the fact, that ~Client (this=0x83b86d0) seems to get
> > called, althought no constructor has ever been called. Thought I don't
> > think libfam really calls a function, which is Kopete-private. Thus the
> > stack-trace does not 100% show the program flow. I would like to get
> > throught kopete debugging without compiling all my libraries in DEBUG mode.
> 
> If you're developing, I can really recommend compiling with full debug info. 
> It's surely worth the effort.

Well, KDE is more a hobby. And I will not replace my whole system for KDE 
development. So I do debugging in a limited environment, develop a fix, 
add it to SVN and afterward wait for the next release, so the fix applies 
to my system :-)

> Sometimes when I have strange bugs/crashes and gdb gives confusing messages, I 
> use valgrind, since it can be quite good at telling what's going on.

The problem with valgrind was, that it ended when the crash came. But 
maybe --nocrashhandler helps here too.

My basic problem with valgrind and KDE tools is, that there is much too 
much leaking memory at the end of a program run. Some of it coming from 
the X-libraries, others from other places. It is really hard to track down 
memory loss, when there is so much loss (probably caching based) in the 
base libraries.

Ciao
-- 
http://www.dstoecker.de/ (PGP key available)
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]