Stupid questions about debugging kde apps
ralf.habacker at freenet.de
Sun Feb 3 19:15:58 GMT 2008
Thiago Macieira schrieb:
> Marc Espie wrote:
>> In my opinion, there's a lot of stuff missing in DEBUG (the one in
>> - 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.
> Two possible reasons for that:
> 1) code being called from inside kDebug(), which means it won't get called
> from a release-mode build
> or 2) a real heisenbug that goes away in a debug-mode build simply because
> of different compiler flags or memory layout.
> To turn off debugging completely, set the macro that is listed in
>> - 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 ?)
> They are documented:
> --nocrashhandler Disable crash handler, to get core dumps
> --nofork Do not run in the background.
> The --nofork option only applies to applications deriving from
> KDE applications are normal applications. A KUniqueApplication will
> fork(): the parent process exits, the child continues. kdeinit is
> just .the master app launcher: fork + exec.
>> - 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...
> KDE_SLAVE_DEBUG_WAIT=protocol kdeinit4
> Works by calling raise(SIGSTOP) in the beginning of the ioslave, before
> control is passed to the slave code. I don't care about platforms where
> raise() doesn't work.
on win32 the environment variable KDE_SLAVE_DEBUG_WAIT is also supported
for msvc builds kioslave calls a just in time debugger (for example
windbg from the Micrososft Debugging Tools installed with windbg -i or
the build in just in time debugger of MSVC VC++ 2005). For gcc builds
kioslave starts gdb, which attaches to the running kioslave process. In
both cases kioslave is stopped before control is passed to the slave code.
for the concret implementation.
More information about the kde-core-devel