Created attachment 24726 [details] [review] Xorg log from crash I have been experiencing random crashes with xf86-video-ati driver 6.12.2 (mesa 7.4) the crashes occur some time after login (1 to 2 hours or more, if I'm lucky :)). X restarts every time after the crash. After the crash I'm able to login normally to KDE but if I try to VT switch or login to console the screen gets corrupted. It displays the console but everything is garbled and compressed at the top of screen. I need to reboot to be able to login to console. It doesn't seem to exist a special event that triggers the crash. Although it seems to occur more often when opening a new window, but also occurred in other situations. This can be just a coincidence. My system Configuration: ATI Mobility Radeon X1600 - toshiba laptop A100 openSUSE 11.1with KDE4 4.2.69 and desktops effects enabled and using EXA xf86-video-ati driver 6.12.2 (mesa 7.4). Today I updated drm from git but the crashes continued. I don't know if it is related but I also noticed one time the rendering of the inside of the windows(2D) was really slow, but the desktops effects were still fast and I couldn't notice an increase of the cpu usage. I tried changing VT I'll try XAA to see if get the same result, but EXA is so great... I don if it is relevant but I had the same problems the last time I tried the radeon driver: xorg 7.2 mesa 7.2 xf86-video-ati 6.9.0 opensuse 11.1 with KDE 4.2.0 With this configuration the crashes of the x server occurred usually just some minutes after login. In this case X didn't restarted, the desktop would get frozen, some time with a jerky slow moving mouse, not even magic keys could restart the system. I don't have a log from this crash. I tested with radeonhd 1.2.5 but I also get random crashes, but with this driver X doesn't restart the system just freezes. With fglrx I dont have this crashes but I prefer the radeon one. I'm available to give more info if need.
Created attachment 24727 [details] xorg.conf
This crash is in the xserver exa code. Any chance you could get a better backtrace with gdb? http://wiki.x.org/wiki/Development/Documentation/ServerDebugging
Created attachment 24778 [details] gdb output from x server crash
Comment on attachment 24778 [details] gdb output from x server crash I don't know if the attached gdb output is usseful, I only instaled the x server and xf86-video-ati debuginfo packages.
(In reply to comment #4) > (From update of attachment 24778 [details]) > I don't know if the attached gdb output is usseful, [...] Unfortunately it isn't, as it's not from the crash but from a SIGPIPE signal, which is normal as part of the X server operation. You can just tell gdb to continue at such prompts and tell it not to stop execution on SIGPIPE using handle SIGPIPE nostop From the log file it looks like it crashes in FindGlyphRef which isn't part of EXA either, reassigning again.
Created attachment 24787 [details] x server backtrace debug I hope this backtrace is better than the previous one. X ended with a SIGABORT.
This backtrace looks like it might be related to bug 17358. It is however different from the backtrace in the log file you attached first.
Created attachment 24827 [details] another x server gdb backtrace from crash I updated xserver to 1.6.1. My x server also crashed with XAA, but its crashes more often with EXA. The attached gdb backtrace was using option EXA, as the previous ones. It seems different from the previous one.
Created attachment 24840 [details] x one more server gdb backtrace from crash Maybe I'm submitting too many backtraces that are useless, but my system is always crashing and my other option is to return to fglrx from october 2008 (the last on that worked for me). Also I instaled Ubuntu 9.04 Beta (radeon driver,EXA and compiz) in the same machine and I got no x crashes. I only tested for some hours, but with opensuse and kde4 that was probably enought to get a crash. I even updated my kernel to 2.6.29 (opensuse package) and X xerver crashed, no backtrace or log from this one. Sometimes X restarts but there is no backtrace on the log file. Probably this is related to kde/qt. What else can I do to help tracing this bug? Should I make a bug report with kde or opensuse?
(In reply to comment #9) > Maybe I'm submitting too many backtraces that are useless, [...] Your latest backtraces aren't useless, but all different. This could mean there's actually several different problems, although they could just all be different symptoms of possibly the same memory corruption. See bug 17358 for some ideas for tracking down the memory corruption. > Also I instaled Ubuntu 9.04 Beta (radeon driver,EXA and compiz) in the same > machine and I got no x crashes. I only tested for some hours, but with opensuse > and kde4 that was probably enought to get a crash. > What else can I do to help tracing this bug? Should I make a bug report with > kde or opensuse? KDE is certainly not directly responsible for an X server crash. Before suspecting it's an OpenSUSE specific issue, you should try to eliminate all other variables, in particular different upstream versions of xserver, xf86-video-ati and mesa, the use of compiz vs. kwin, ... BTW, does the problem only happen with the kwin OpenGL backend or also with XRender? If the former, maybe you could try if the Mesa patch from http://www.nabble.com/-rfc-patch--dri-drawable-ref-counting-to23070817.html helps.
Updated to mesa 7.4.1 (opensuse packages), still crashes with the opengl backend. No crashes with kwin Xrender backend. I will try to compile mesa with the patch you mencioned: http://www.nabble.com/-rfc-patch--dri-drawable-ref-counting-to23070817.html
Created attachment 25035 [details] Xorg log - crash after patched mesa I patched mesa from git with the patch refered in comment #10. The X server still crashes using the kwin opengl backend.
Created attachment 25038 [details] xorg log -server crash after loading compiz I switched from kwin composite to compiz and just after loading compiz (0.8.2) the server crashed. I'm going to give a try to compiz to see If i get other crashes or not.
I can reproduce the server crash refered in my previous comment (#13), I get the same backtrace. To reproduce the crash I do the following: kde4 system settings >> Default applications >> Window manager >> Use default window manager(kwin)<->Use a different window manager: Compiz. In the last option if when I hit apply to switch from kwin->compiz or compiz->kwin the server crashes. I dont know if this crash is related with the other crahes.
Created attachment 25460 [details] [review] Lose current GLX context if its drawable or readable goes away I was able to reproduce the last crash by restarting compiz, and this xserver patch seems to fix it. Can you confirm? The other crashes could have been caused by a Mesa r300 driver memory use-after-free issue which has been fixed in mesa Git master and mesa_7_4_branch.
Sorry for the delay. I patched opensuse source rpm with your patch and I still can reproduce the crash when starting compiz. I dont have a log this time. I also updated radeon+drm+mesa on the 2009-05-06 from git master and now x server crashes less often for sure (previously it crashed within hours now it is within days). If I'm able to I'll try valgrind to debbug the server.
Updated mesa+drm+radeon on the 2009-05-21 from git master. Since then I haven't had a single xserver crash :). Should I mark this bug as fixed? I also reported here having a crash while switching from compiz to kde4 and vice versa (X still crashes doing this), should I create a new bug report for this one? I think I should have done that before. Sorry for all the questions but I'm a newbie reporting bugs here.
(In reply to comment #17) > > I also reported here having a crash while switching from compiz to kde4 and > vice versa (X still crashes doing this), should I create a new bug report for > this one? I think I should have done that before. Right, but I think it should be fixed by the patch I attached here, which is also in xserver Git now.
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.