Created attachment 15083 [details]
xorg-logfile with crash
Today i updated the radeonhd to the latest version and immediately notices that starting urxvt (rxvt-unicode http://software.schmorp.de/pkg/rxvt-unicode.html )
with -depth 32 or URxvt*depth: 32 in .Xdefaults results in a SIG11 (at least i read that from the attached log) to the xserver
Created attachment 15084 [details]
There are only 'skip'ped commit left to test.
The first bad commit could be any of:
We cannot bisect more!
So the bug was introduced somewhere in there.
I get this with the radeon driver (7500 M7 card), but only when urxvt quits.
The SEGV occurs when the gl driver tries to free something, so it seems to be a double free, and in the extension rather than in the driver.
(In reply to comment #3)
> I get this with the radeon driver (7500 M7 card), but only when urxvt quits.
> The SEGV occurs when the gl driver tries to free something, so it seems to be a
> double free, and in the extension rather than in the driver.
This sounds like
in the "Module" section of your xorg.conf. Even if there's no 3d support available. If there is, but you do not want to use it, move the dri kernel module somewhere where it's not found.
Michael, could you try this as well? If urxvt tries to do something with OpenGL that could be the case. Wonder why this has something to do with the radeonhd version, though.
well my log says
(II) "dri" will be loaded by default.
Fair enough. So different issue.
noticed today that the crash only occurs when i comment out
Option "Accelmethod" "xaa"
in the configfile
if it is enabled, no crsh occurs.
so it seems that something in the setup of the default path (which is also xaa) is broken or at least doesn't behave the same way as the setting of the config-option does
(In reply to comment #7)
> noticed today that the crash only occurs when i comment out
> Option "Accelmethod" "xaa"
> in the configfile
> if it is enabled, no crsh occurs.
> so it seems that something in the setup of the default path (which is also xaa)
> is broken or at least doesn't behave the same way as the setting of the
> config-option does
That helps a lot - I'll look into that!
Does this issue occur with the preferred ati driver (xf86-vide-ati)? If so, please move this to the Driver/Radeon component.
Development of radeonhd has pretty much halted and development focus is on the ati driver. Please see http://www.x.org/wiki/radeonhd
If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.
Closing due to lack of response. Please reopen and move to the Driver/Radeon
component if this issue persists with xf86-video-ati