Why is debugging under Linux such a pain

Why is debugging under Linux such a pain

[Otto Wyss]

Sorry if this is off topic here but IMO this _has_ to be discussed in a
broader audience since it probably has a rather large impact about the
acceptance of Linux even if it isn't the kernel's fault.

I just build the minimal sample of the wxWidgets framework and it
crashed when playing around with the menu. Well crashing might happen so
I took out GDB and tried to discover the reason. But when the sample
crashed I couldn't switch to the terminal where GDB was running. No
mouse or keyboard input was possible. I was completely stuck, IMO
something _never_ should happen. Who's to blame for this situation:
wxWidgets, GDB, GCC/G++, X or the Linux kernel? Or any combination?

Luckally I wasn't completely stuck since I started X with 'startx' and
could kill X with ctrl-alt-backspace. Also ctrl-alt-f1 worked so I could
switch to the console. At least I could shutdown my computer. Anyway the
above situation should not happen.

Back to debugging with GDB, I knew it's possible to to debug from the
console (which worked normal) but I wasn't sure how the assign could be
done. Of course 'man gdb' didn't show how, worse it didn't give any
hints where to look further. At this point I got upset and lost interest
and instead trying to produce a fix I simply made a bug report.

There are more issues with GDB which don't belong here but make
debugging under Linux just painful. I'm willing to spend a lot of my
spare time for a free system usable by anyone but when I have to do
debugging the fun is over and fast loose interests.

Does anyone has an idea how debugging under Linux can be improved to an
acceptable state?

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wxguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

Re: Why is debugging under Linux such a pain

[Marko Macek]

Otto Wyss wrote:
 > No
> mouse or keyboard input was possible. I was completely stuck, IMO
> something _never_ should happen. Who's to blame for this situation:
> wxWidgets, GDB, GCC/G++, X or the Linux kernel? Or any combination?

This is by design in X. XGrabKeyboard and XGrabPointer are usually to 
blame. Sometimes XGrabServer (not that a normal app should ever need to 
call it). Often things are made worse by a toolkit that doesn't flush
Ungrab operations immediately.

Some toolkits (Qt) have a --nograb option and sometimes activate it 
automatically when being debugged.

A workaround:

- check out X config setting AllowDeactivateGrabs, enable it (see also 
AllowClosedownGrabs)

- Ctrl+Alt+Numpad-Divide will then allow you to ungrab the keyboard and 
mouse.

Warning: this might break your screen saver display lock function due to 
an incorrect design of the lock mechanism (it uses the same "X display" 
as your login session).

It would be nice if display lock programs used a separate X display 
(some kind of "virtual" display support might be nice to have, mainly 
for performance).

This would also be good for running games. Currently it's a a major 
problem when a game freezes and there is no way to get back to the 
desktop without killing X.

It would of course need to interact with current console switching 
mechanism.


	Mark

Re: Why is debugging under Linux such a pain

[Tomasz Rola]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 5 Feb 2005, Marko Macek wrote:

[...]
> It would be nice if display lock programs used a separate X display 
> (some kind of "virtual" display support might be nice to have, mainly 
> for performance).

I would try VNC for this, at least for debugging. But I don't really know
if it would have worked. My distro (Debian) has VNC packed nicely
(vncserver and xvncviewer packages), others should have it too. So the
trial should be rather quick if you use such Linux flavor.

I mean, open debugged app on a VNC display and have gdb on real one. You
can also view your VNC display with a viewer in a window and it should not
mess your real X session. But I may be wrong, never tried VNC for such
kind of work even though I use it very often.

One can also do similar thing with simply having two X sessions on two
consoles, I suppose. However, frequent switching between them may not be
very healthy for hardware.

Well, I'm just thinking loudly.

Regards,
Tomasz Rola

- --
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBQgVjjBETUsyL9vbiEQLKIQCfb0g29u44eOiRWSC2t8/I27KvJuwAoLun
pWXajzIauR1ebxYX17Xyinos
=Fkjv
-----END PGP SIGNATURE-----

[OT] Re: Why is debugging under Linux such a pain

[Kyle Moffett]

On Feb 05, 2005, at 19:23, Tomasz Rola wrote:
> On Sat, 5 Feb 2005, Marko Macek wrote:
> [...]
>> It would be nice if display lock programs used a separate X display
>> (some kind of "virtual" display support might be nice to have, mainly
>> for performance).
>
> I would try VNC for this, at least for debugging. But I don't really 
> know
> if it would have worked. My distro (Debian) has VNC packed nicely
> (vncserver and xvncviewer packages), others should have it too. So the
> trial should be rather quick if you use such Linux flavor.

You could also try Xnest, which runs a second X-server within a window 
of
the primary X-server, except without most of the extra overhead of VNC 
or
other image-based solutions. Xnest can even handle different bit-depths
than the primary display, and only slightly modifies most X calls, 
except
for the ones that affect global state, which it processes internally.


Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------

Re: [OT] Re: Why is debugging under Linux such a pain

[Tomasz Rola]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 5 Feb 2005, Kyle Moffett wrote:

> You could also try Xnest, which runs a second X-server within a window 
> of
> the primary X-server,

Yes, this is a good idea...

> except without most of the extra overhead of VNC 

...but I'm not sure if this overhead is noticeable in normal case. I have
just tried to watch film on xvncviewer (same computer, i.e. no network
except localhost) and it was watchable in full screen (800x550 emulated in
window) and even more so when I switched mplayer to window mode. Quake2
also was running quite nicely in 640x400.

BTW, I am using TightVNC and my cpu is Athlon underclocked down to 900
MHz (well, I've decided full 1.8 GHz scared me a lot and besides,
who needs it to run so fast? and why they don't make 7.14 MHz computers
anymore?).

Of course, in terms of cpu cycles, mplayer and Xvnc together took about
35% of CPU in top, while mplayer on real X took only about 3-5% due to the
gfx card doing all the work (seemingly). So the overhead is indeed quite
big.

For a "simple app with few menus", the choice probably doesn't matter
anyway.

> Cheers,
> Kyle Moffett

Regards,
Tomasz Rola

- --
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola@bigfoot.com             **

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQA/AwUBQgWX2RETUsyL9vbiEQKLVACgsZeOt11+VUICCITjMBQX9ZTrCQQAoPHa
58IkuL68hTKtZTrQdi70DYV9
=FIkn
-----END PGP SIGNATURE-----