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