Bug 90182

Summary: [radeonsi]Qt Applications won't start on the dedicated GPU (SIGABRT)
Product: Mesa Reporter: Paul <paul>
Component: Drivers/Gallium/radeonsiAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact: Default DRI bug account <dri-devel>
Severity: normal    
Priority: medium CC: paul
Version: 10.5   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: GLXINFO of radeon
GLXINFO of Intel
GDB Trace for openglunderqml
GDB Trace for kdenlive using KWin and OpenGL
GDB Trace for kdenlive using KWin and Xrender
Modified PKGBUILD for debug build of mesa
Makepkg.conf used for building mesa
Radeonsi debug log (hopefully with symbols)
Xorg.0.log after command execution
Updated GDB trace for openglunderqml
Updated glxinfo Intel
Updated glxinfo radeon
Updated Xorg.0.log

Description Paul 2015-04-26 09:24:17 UTC
Created attachment 115334 [details]
GLXINFO of radeon

Hi, I was trying to test the new kdenlive development build I noticed that it wouldn't even start with DRI_PRIME=1 kdenlive.
I immediatedly got a SIGABRT
Same happened with an easy example program from the Qt project "openglunderqml"

"LANG=C R600_DEBUG=cs DRI_PRIME=1 QSG_INFO=1  '/home/paul/hybrid test/build-openglunderqml-Desktop-Debug/openglunderqml'                                                                                                                     
QML debugging is enabled. Only use this in a safe environment.                                                                       
openglunderqml: dri2.c:518: dri2_allocate_textures: Assertion `drawable->textures[statt]' failed.                                    
Abgebrochen (Speicherabzug geschrieben)"

As Xonotic worked more or less ok on the radeon I filed a bug report at the Qt project https://bugreports.qt.io/browse/QTBUG-45686
Laszlo Agocs from the Qt project states the following: 
"Might be a difficult one and not just because we lack any such hw to test on. Cannot do much when glXMakeCurrent() crashes deep inside the driver.
Any chance for a backtrace with symbols? In the absence of that running with QSG_INFO=1 could be helpful too.
Anyway, it's most likely happening in QGLXContext::queryDummyContext() where we attempt to make a pbuffer surface current in order to query a few GL things.
Other apps may not rely on pbuffers and thus may not exhibit the issue."

I'm not a programmer so please go easy on me. If you need additional info let me know (and maybe tell me how to fetch it for you ;) )

Thanks!

Hardware: HP EliteBook 850 G1 with Intel (HD4400) / AMD (HD8750M, OLAND) hybrid graphics
Software:
ArchLinux (Antergos)
Linux 3.19.3
mesa 10.5.4 Intel / Radeon exact glxinfo outputs are attached
Qt 5.4.1
Comment 1 Paul 2015-04-26 09:24:44 UTC
Created attachment 115335 [details]
GLXINFO of Intel
Comment 2 Paul 2015-04-26 09:25:34 UTC
Created attachment 115336 [details]
GDB Trace for openglunderqml
Comment 3 Paul 2015-04-26 09:27:50 UTC
Created attachment 115337 [details]
GDB Trace for kdenlive using KWin and OpenGL
Comment 4 Paul 2015-04-26 09:28:47 UTC
Created attachment 115339 [details]
GDB Trace for kdenlive using KWin and Xrender
Comment 5 Michel Dänzer 2015-04-27 08:24:19 UTC
Please attach at least one new gdb trace with debugging symbols available for /usr/lib/xorg/modules/dri/radeonsi_dri.so.
Comment 6 Paul 2015-04-27 09:52:24 UTC
I tried building mesa with debug symbols but somehow gdb says that there are still none for /usr/lib/xorg/modules/dri/radeonsi_dri.so

This is what I did: 
I used the archlinux PKGBUILD and added --enable-debug to the configure options and 
added "-g -O2" to CFLAGS and CXXFLAGS respectively. This gave me a few packages I then installed. The packages were much larger than the original arch ones so I think the symbols got built.
But when I do LANG=C gdb info /usr/lib/xorg/modules/dri/radeonsi_dri.so
I still get no sysmbols found: 
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from info...(no debugging symbols found)...done.
"/usr/lib/xorg/modules/dri/radeonsi_dri.so" is not a core dump: File format not recognized

Any idea what I did wrong? (I'll attach the PKGBUILD and my makepkg.conf)
Comment 7 Paul 2015-04-27 09:54:14 UTC
Created attachment 115367 [details]
Modified PKGBUILD for debug build of mesa
Comment 8 Paul 2015-04-27 09:54:45 UTC
Created attachment 115368 [details]
Makepkg.conf used for building mesa
Comment 9 Michel Dänzer 2015-04-27 09:55:45 UTC
(In reply to Paul from comment #6)
> "/usr/lib/xorg/modules/dri/radeonsi_dri.so" is not a core dump: File format
> not recognized

It says it's not a core dump, which is correct. Have you tried getting a backtrace of the crash again?
Comment 10 Paul 2015-04-27 10:00:15 UTC
Created attachment 115369 [details]
Radeonsi debug log (hopefully with symbols)
Comment 11 Paul 2015-04-27 10:04:59 UTC
I "think" it worked:

#3  radeon_drm_cs_emit_ioctl (param=param@entry=0x689970) at radeon_drm_winsys.c:594
        ws = 0x689970
        cs = <optimized out>
        i = <optimized out>
#4  0x00007fffdf12a157 in impl_thrd_routine (p=<optimized out>) at ../../../../../include/c11/threads_posix.h:87
        pack = {func = 0x7fffdf12a920 <radeon_drm_cs_emit_ioctl>, arg = 0x689970}
Comment 12 Emil Velikov 2015-04-27 17:12:11 UTC
Paul small tip from a fellow Arch user:
The quickest/easiest way to get debug symbols is to add 'debug' in the OPTIONS array of the PKGBUILD and rebuild the package [1]. This way separate *debug* packages will be created.

The configure's --enable-debug does something a big different :-)

[1] https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces#PKGBUILD
Comment 13 Paul 2015-04-27 19:14:28 UTC
Thanks Emil, I tried that just now but somehow I still got the whole packages presumably with the symbols included. 
Might be because I wasn't aware that you could add that PKGBUILD option and edited my makepkg.conf instead. Anyway I hope I got something useful with the last trace. :-)
Comment 14 Michel Dänzer 2015-04-28 08:21:30 UTC
Please attach the /var/log/Xorg.0.log file corresponding to the problem.
Comment 15 Paul 2015-04-28 08:49:10 UTC
Created attachment 115392 [details]
Xorg.0.log after command execution

This is my Xorg.log after I executed LANG=C R600_DEBUG=cs DRI_PRIME=1 QSG_INFO=1 gdb  '/home/paul/hybrid test/build-openglunderqml-Desktop-Debug/openglunderqml'
Comment 16 Paul 2015-06-26 00:08:22 UTC
Created attachment 116720 [details]
Updated GDB trace for openglunderqml

Hi everyone!
Here is an updated trace created under Kubuntu 15.04. I did this because it's way easier getting debugging symbols here (and sddm stopped working on arch for some reason)
I'll also attach the new updated versions of glxinfo and Xorg.0.log
Cheers!
Comment 17 Paul 2015-06-26 00:09:36 UTC
Created attachment 116721 [details]
Updated glxinfo Intel
Comment 18 Paul 2015-06-26 00:10:17 UTC
Created attachment 116722 [details]
Updated glxinfo radeon
Comment 19 Paul 2015-06-26 00:11:29 UTC
Created attachment 116724 [details]
Updated Xorg.0.log
Comment 20 GitLab Migration User 2019-09-25 17:51:58 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1216.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.