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
Created attachment 115335 [details] GLXINFO of Intel
Created attachment 115336 [details] GDB Trace for openglunderqml
Created attachment 115337 [details] GDB Trace for kdenlive using KWin and OpenGL
Created attachment 115339 [details] GDB Trace for kdenlive using KWin and Xrender
Please attach at least one new gdb trace with debugging symbols available for /usr/lib/xorg/modules/dri/radeonsi_dri.so.
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)
Created attachment 115367 [details] Modified PKGBUILD for debug build of mesa
Created attachment 115368 [details] Makepkg.conf used for building mesa
(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?
Created attachment 115369 [details] Radeonsi debug log (hopefully with symbols)
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}
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
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. :-)
Please attach the /var/log/Xorg.0.log file corresponding to the problem.
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'
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!
Created attachment 116721 [details] Updated glxinfo Intel
Created attachment 116722 [details] Updated glxinfo radeon
Created attachment 116724 [details] Updated Xorg.0.log
-- 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.