Hello,
When I use GDB to debug a multithreaded opengl application the SYSTEM (!!!) freezes and I have to reboot the computer, this is 100% reproducible. The application works fine when I run it outside GDB. The system freezes only after a few NEXT commands in GDB. From the callstack below, it seems the ATI drivers are causing this problem.
I tried different drivers, different kernels and different X configs. Unfortunately nothing seems to work for me.
Is it possible to use GDB to debug multithreaded OpenGL applications along with ATI GPUs ?
My computer spec are:
RADEON HD 6700
16 GB RAM
Ubuntu 12.04.2 LTS
Kernel - 3.2.0-41-generic
Proprietary drivers (I tried 4 different versions that come with the distribution)
I also tried solution suggested in http://www2.ati.com/drivers/linux/readme0328.txt without positive results, the system hangs and I have to reboot the computer:
20. Compatibility with GDB, TotalView and other debuggers
The driver has to go trough critical sequences for its normal operation
that might produce memory loss or other non nice situations. For this
it has to block some of the task interruption signals (like suspend)
and to re-enable those signals afterwards.
As of now there is a known side effect due to above behaviour. Debugger
applications attached to OpenGL programs will be no longer responsive
after a certain level of OpenGL initialisation is done and the system
is further executing multiple OpenGL threads or applications. The effect
is not neccessarily a deterministic one.
In order to let developers debug their multi threaded OpenGL applications
despite this there was an option added to XF86Config-4 which allows then
to turn of the blocking in genereal. Since that also again introduces the
risk of suffering memory leaks in combination with specific user activity
the blocking should only be disabled unless there is a real need for it.
Locate the below line in your XF86Config-4 file:
Option "BlockSignalsOnLock" "<state>"
The entered state for the key UseFastTLS has this meaning:
state meaning description
------------------------------------------------------------------------
off no block The driver will not use signal blocking. (for debuggers)
on use block The driver does block the signals for locking. (default)
Note: As of now it is uncertain which is the real origin of the problem.
As of now it does look like the debugger application is getting in some
trouble because of not getting back the debugging control after the lock
condtion was removed by the driver. This might be further investigated.
Below you can see a partially output from Xorg.0.log after a crash:
[ 61601.338] [mi] EQ overflowing. Additional events will be discarded until existing events are processed.
[ 61601.338]
Backtrace:
[ 61601.351] 0: /usr/bin/X (xorg_backtrace+0x26) [0x7f8d1a9309e6]
[ 61601.351] 1: /usr/bin/X (mieqEnqueue+0x263) [0x7f8d1a9110c3]
[ 61601.351] 2: /usr/bin/X (0x7f8d1a7a8000+0x62a34) [0x7f8d1a80aa34]
[ 61601.351] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7f8d0b11c000+0x5d88) [0x7f8d0b121d88]
[ 61601.351] 4: /usr/bin/X (0x7f8d1a7a8000+0x8af37) [0x7f8d1a832f37]
[ 61601.352] 5: /usr/bin/X (0x7f8d1a7a8000+0xb0d3a) [0x7f8d1a858d3a]
[ 61601.352] 6: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f8d19ace000+0xfcb0) [0x7f8d19addcb0]
[ 61601.352] 7: /lib/x86_64-linux-gnu/libc.so.6 (ioctl+0x7) [0x7f8d18a2a537]
[ 61601.352] 8: /usr/lib/fglrx/libatiuki.so.1 (ukiGetLock+0x7b) [0x7f8d15edf02b]
[ 61601.352] 9: /usr/lib/x86_64-linux-gnu/xorg/extra-modules/extra-modules.dpkg-tmp/modules/drivers/fglrx_drv.so (xdl_xs111_swlDriLock+0x7b) [0x7f8d1645df0b]
[ 61601.352] 10: /usr/lib/x86_64-linux-gnu/xorg/extra-modules/extra-modules.dpkg-tmp/modules/drivers/fglrx_drv.so (xdl_xs111_swlDriDoWakeupHandler+0x3b) [0x7f8d1645d5db]
[ 61601.352] 11: /usr/lib/x86_64-linux-gnu/xorg/extra-modules/extra-modules.dpkg-tmp/modules/drivers/fglrx_drv.so (0x7f8d15ff3000+0x45338a) [0x7f8d1644638a]
[ 61601.352] 12: /usr/lib/x86_64-linux-gnu/xorg/extra-modules/extra-modules.dpkg-tmp/modules/drivers/fglrx_drv.so (xdl_xs111_swlDriWakeupHandler+0x74) [0x7f8d1645d514]
[ 61601.352] 13: /usr/bin/X (WakeupHandler+0x6b) [0x7f8d1a7fa7eb]
[ 61601.352] 14: /usr/bin/X (WaitForSomething+0x1b6) [0x7f8d1a92dde6]
[ 61601.352] 15: /usr/bin/X (0x7f8d1a7a8000+0x4e5f2) [0x7f8d1a7f65f2]
[ 61601.352] 16: /usr/bin/X (0x7f8d1a7a8000+0x3d7ba) [0x7f8d1a7e57ba]
[ 61601.353] 17: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xed) [0x7f8d1895f76d]
[ 61601.353] 18: /usr/bin/X (0x7f8d1a7a8000+0x3daad) [0x7f8d1a7e5aad]
[ 61601.353] [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack.
[ 61601.353] [mi] mieq is *NOT* the cause. It is a victim.
[ 61633.402] [mi] EQ overflow continuing. 100 events have been dropped.
[ 61633.402]
I've also attached to this post my xorg.conf file
I'd appreciate any ideas or feedback regarding this issue.
Regards,
Pablo.
