AnsweredAssumed Answered

X server crashes when debugging multithreaded OpenGL application with GDB!!!!!

Question asked by morgolock on Apr 29, 2013

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.

Attachments

Outcomes