Did you install AMD Catalyst driver on your system?
If not, can you please try installing AMD Catalyst driver 13.1 on your machine and then run CodeXL?
You can download AMD Catalyst for Linux OS at:
you can choose your configuration and download AMD Catalyst at:
Thanks for your report, we are trying to reproduce the issue in our labs.
Note that answering "Yes" to the dialog window should allow you continue debugging, though there's a chance it will cause CodeXL to be unstable.
Could you please perform the following diagnostics to help us understand the issue?
1. In the same console as you would use to run CodeXL, please run the following command:
What is the output?
2. Try running CodeXL as the superuser (su or login as root, not "sudo CodeXL"). Does this change anything?
3. Try running the setting command (aticonfig --sb off) as the superuser (again, su or login as root, not "sudo aticonfig ..."). Does this change anything?
# aticonfig --get-pcs-key=DDX,BlockSignalsOnLock
Error: Key DDX,BlockSignalsOnLock not found in PCS database
# aticonfig --sb off
Warning: Option 'BlockSignalsOnLock' doesn't affect running session.
Saving back-up to /etc/X11/xorg.conf.fglrx-3
We tried with root, and we're getting the same issue. It hangs when the profiler is enabled:
AMD CodeXL GPU Profiler V2.6.2153 is Enabled
after it's enabled, there's 100% CPU - but no output.
We also moved the ~/.amd directory aside to make sure it wasn't interfering.
The same is true for the AMD driver version 12.10.05 (release UNSUPPORTED-12.10.17) aka 13.3_beta2.
I assume the option was removed from newer versions, but it appears that it is still needed for CodeXL to work. When starting an application in debug mode, it complains that one has to run "aticonfig --sb off". The application crashes immediately after starting. This is true for both a project of my own and the AMDTTeapot example.
The call stack support of CodeXL seems rather poor, but this is what I got out of it (I had to manually copy the instruction pointer addresses):
?? - -- 0xffffffffffffffff
?? - fglrx_dri.so -- 0x00007fffee22e0af
?? - fglrx_dri.so -- 0x00007fffee1305f8
?? - fglrx_dri.so -- 0x00007fffeee5da79
?? - fglrx_dri.so -- 0x00007fffef82bf8b
?? - fglrx_dri.so -- 0x00007fffef87f001
?? - -- 0xffffffffffffffff
What you are describing is supposed to be an unrelated issue (i.e. the original problem is also showing up on your machine, but is not cauing the crashes) - this also reproduced for an internal user, who fixed it by updating their gtkext library.
sudo apt-get install libgtkglext1
And seeing if that helps the crashes.
The next CodeXL version will have better defined dependencies in the installer packages, so this should not happen after that.
Thanks for your report,
I am having the same issue, have you found a solution? I am using the latest driver on kaveri
[ 25.482] (II) Loading /usr/lib/xorg/modules/drivers/fglrx_drv.so [ 25.659] (II) Module fglrx: vendor="FireGL - AMD Technologies Inc." [ 25.659] compiled for 126.96.36.1996, module version = 15.20.3 [ 25.659] Module class: X.Org Video Driver
and I see
[ 26.146] Loading extension AMDXVOPL [ 26.146] Loading extension AMDXVBA [ 26.146] (II) fglrx(0): Enable composite support successfully [ 26.146] (WW) fglrx(0): Option "BlockSignalsOnLock" is not used [ 26.146] (WW) fglrx(0): Option "VendorName" is not used [ 26.146] (WW) fglrx(0): Option "ModelName" is not used [ 26.146] (II) fglrx(0): X context handle = 0x1
CodeXL says this is bad... what to do now?
If the BlockSignalsOnLock option is indeed off, there should be no problem (other than the message - you can press "yes" and debugging will continue as normal).
If the "aticonfig --sb off" didn't do anything, try running "amdconfig --sb off" instead.
aticonfig and amdconfig seem to be doing same changes to the xorg.conf file.
Apparently my problem was because I was using x-forwarding because the example seems to be working on console. But it is still annoying that CodeXL says it may crash etc. unless the option is set, everytime I start it.
Do you know if virtualgl can be used to remotely debug the opengl applications?
Exact same issue with the teapot example here on Debian stretch with fglrx 15.9.
Same stacktrace. Same warning in CodeXL when starting to debug. Same message that setting is ignored in xorg.conf.
I am on not using x-forwarding, since I am working locally.