Hard times debugging under KDevelop
Waldo Bastian
bastian at kde.org
Fri Jan 23 13:23:14 GMT 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri January 23 2004 14:07, Andras Mantia wrote:
> Hi,
>
> A little bit offtopic, but I have problem with debugging under KDevelop
> and the problem happened only recently and in some way it is related to
> KDirWatch, thus I'm posting it here. The symptoms: debugging often stops
> when next/step/print is issued in gdb (well, from KDevelop, but basicly
> this is what KDevelop sends to gdb). I can interrupt the execution and I
> always see that the program is "locked" in libpthread.so.0. Here is an
> example:
>
>
> (gdb) next <---- here I don't get back the gdb command prompt
>
> Program received signal SIGINT, Interrupt.
> 0x41a00a78 in write () from /lib/libpthread.so.0
> (gdb) info thread
> * 1 Thread 16384 (LWP 11288) 0x41a00a78 in write () from
> /lib/libpthread.so.0 (gdb) backtrace
> #0 0x41a00a78 in write () from /lib/libpthread.so.0
> #1 0x40ae2bb4 in __JCR_LIST__ () from /opt/kde-cvs/lib/libkio.so.4
> #2 0x4094a7b4 in KDirWatchPrivate::dnotify_sigio_handler(int, siginfo*,
> void*) () from /opt/kde-cvs/lib/libkio.so.4
You may want to ignore this interrupt. I can explain why you get it:
When using dnotify, KDirWatcher gets notified about changes via so called
"real-time interrupts". A property of these interrupts is that they "stack
up"; when you get 4 of such interrupts, your process will be interrupted 4
times. With normal interrupts, chances are you only get interrupted once and
all interrupts up to that point are considered handled by that.
If you now get a lot of such real-time interrupts and don't handle them fast
enough, the stacking up becomes a problem, you basically get a stack
overflow. To prevent that you no longer get any more real-time interrupts,
but a single SIGINT to indicate "you weren't able to read your real-time
interrupts fast enough, some have been lost." KDirWatch is supposed to handle
this situation gracefully, it's not a big problem.
It's obvious why you run into this when debugging. If you step through your
program KDirWatch may get a bunch of these real-time interrupts but your
program will not be able to react to them because it is stuck in the
debugger.
Hope this helps,
Cheers,
Waldo
- --
bastian at kde.org -=|[ KDE: K Desktop for the Enterprise ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQFAESBCN4pvrENfboIRAlJ/AJ0WTbSYkfYCs0FEgErWY6hTf53VRgCgimKg
CRKb4cqfpZ0zTvmgp/Ga0ow=
=ksnY
-----END PGP SIGNATURE-----
More information about the kde-core-devel
mailing list