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

List:       kde-core-devel
Subject:    Stupid questions about debugging kde apps
From:       Marc Espie <espie () nerim ! net>
Date:       2008-02-03 11:56:19
Message-ID: 20080203115619.GA13700 () lain ! home
[Download RAW message or body]

In my opinion, there's a lot of stuff missing in DEBUG (the one in
kdelibs).

- is there a magical cmake settings to compile applications with
debugging info, BUT without any of the extra messages ? I need this
because of a few heisenbugs, I've got at least two or three instances
of crashes that go away when I compile with full debug info, so I
suspect that some of the debug code does have side-effects.

- should document stuff like -nofork along with -nocrashhandler... any
apps that don't react to -nofork ?  Writing out the basic kde app model
in there would make sense (is it still fork() from kdeinit ?)

- what's the protocol about kioslave debugging ? Especially when you're
not on linux, you do not get symbol backtrace. This is really poorly
documented... I found out about DBUS_BLOCK_ON_ABORT, which is good.
Now I'm stuck (don't laugh) because I actually do not know which app it
is running, so I don't know which symbol-set to load...

(coincidentally, I have no idea why, but https breaks on OpenBSD, and
ONLY in release mode. It works just fine if I compile kdelibs in full
debug mode... but then, since https is pretty verbose, there could be
any kind of async race in there....

I know that most of this is probably very basic material for people used
to hacking on kde, but I have only loosely followed the kde3 -> kde4
transition, and I suspect there might be lots of people out there with
`narrow focus', who only want to debug one specific app without needing
to look all over the place to get all the kde runtime model... and 
currently, it gets a bit in the way when you want to debug things...

[and I know I could probably spend one or two hours figuring this out,
but I figure it's better to have definitive info on this, and to record
it once and for all so that every `new' developer doesn't have to
reinvent the wheel each time...]
[prev in list] [next in list] [prev in thread] [next in thread]