0 Replies Latest reply on Apr 29, 2013 12:39 PM by morgolock

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

    morgolock

      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.