Created attachment 14105 [details] Full log file Hi, i'm quite happy today, for the first time since compiz was announced i got it to "almost" run in my hardware. By almost i mean that it starts up nicely, but when i click on a window decoration to move or resize the window a crash happends. This is the little information that i got, from the Xorg.0.log file: Backtrace: 0: /usr/bin/X(xf86SigHandler+0x84) [0x80c3ad4] 1: /usr/lib/dri/r300_dri.so(_mesa_update_texture+0x292) [0xb2dbf6a2] 2: /usr/lib/dri/r300_dri.so(_mesa_update_state_locked+0x148) [0xb2da78a8] 3: /usr/lib/dri/r300_dri.so(_mesa_update_state+0x2a) [0xb2da7d56] 4: /usr/lib/dri/r300_dri.so(_mesa_GetIntegerv+0x76) [0xb2e881ac] 5: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a63a84] Find the full log file attached. This is the hardware that i'm using: Dell D610 laptop with ATI RADEON Card: lscpi shows the following: 01:00.0 VGA compatible controller: ATI Technologies Inc M22 [Mobility Radeon X300] I'm using libdrm, mesa and the xserver from CVS, compiled as of today.
Can you get a full backtrace with gdb?
I just tried to attach gdb to the X server ... unsuccesfully. I have tried two things: 1) Attach gdb to a running X server, after doing it nothing happend, gdb didn't even start to load the libraries 2) Launch X from gdb, this didn't even start the X window server in both cases my machine lock up. I'm going to need some help about how to get a backtrace ...
(In reply to comment #2) > 1) Attach gdb to a running X server, after doing it nothing happend, gdb > didn't even start to load the libraries > 2) Launch X from gdb, this didn't even start the X window server > > in both cases my machine lock up. Sounds like maybe you're trying to do this locally? That's not possible due to gdb and the X server fighting for user interaction, you have to invoke gdb from a remote login. FWIW, option 1) is generally preferable, for 2) you probably have to pass the -kb X server command line option at least.
Please see the instructions on page http://www.x.org/wiki/Development/Documentation/ServerDebugging - they helped me. Ie. first install debug info packages, then start X server on the machine A, login to machine A via ssh from machine B and start gdb in the way mentioned on the page. As for Debian/Ubuntu instructions instead of Fedora used on the wiki page: 1. Install debug info packages with: "apt-get install xserver-xorg-core-dbg xserver-xorg-video-ati-dbg" 2. When ssh:d to the computer, run: "gdb /usr/lib/debug/usr/bin/Xorg $(pidof X)".
Sorry, 2. should have "gdb /usr/bin/Xorg $(pidof X)" instead.
Ok, so i won't be able to get a backtrace until the weekend when i will have another computer with which i can get a remote session.
ok, so here is a bit more information, i didn't recompile anything, but the crash is not exactly the same. It happend when a window went to its standard size after it was maximized. Compiz had a strange behaviour but i guess mesa didn't have anything to do with this problem. This is what i show on the X.org.0.old log: Backtrace: 0: /usr/bin/X(xf86SigHandler+0x84) [0x80c3ad4] 1: /usr/lib/dri/r300_dri.so(_mesa_update_texture+0x292) [0xb2def6a2] 2: /usr/lib/dri/r300_dri.so(_mesa_update_state_locked+0x148) [0xb2dd78a8] 3: /usr/lib/dri/r300_dri.so(_mesa_update_state+0x2a) [0xb2dd7d56] 4: /usr/lib/dri/r300_dri.so(_mesa_GetIntegerv+0x76) [0xb2eb81ac] 5: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a73a84] This is the backtrace that i got from gdb: Program received signal SIGSEGV, Segmentation fault. texture_override (ctx=0x8502f58, texUnit=0x850dc40, enableBits=16, texObj=0x0, textureBit=16) at main/texstate.c:2824 2824 if (!texObj->_Complete) { (gdb) bt #0 texture_override (ctx=0x8502f58, texUnit=0x850dc40, enableBits=16, texObj=0x0, textureBit=16) at main/texstate.c:2824 #1 0xb2def6a2 in _mesa_update_texture (ctx=0x8502f58, new_state=4456448) at main/texstate.c:2919 #2 0xb2dd78a8 in _mesa_update_state_locked (ctx=0x8502f58) at main/state.c:1187 #3 0xb2dd7d56 in _mesa_update_state (ctx=0x8502f58) at main/state.c:1264 #4 0xb2eb81ac in _mesa_GetIntegerv (pname=34038, params=0xbfd5f068) at main/get.c:3741 #5 0xb7a73a84 in ?? () from /usr/lib/xorg/modules/extensions//libglx.so #6 0x000084f6 in ?? () #7 0xbfd5f068 in ?? () #8 0xbfd5f038 in ?? () #9 0xb7f3827d in DRIGetContext () from /usr/lib/xorg/modules/extensions//libdri.so #10 0x081dcf04 in ?? () #11 0x02605cf3 in ?? () #12 0x0807f9e1 in LookupIDByType () #13 0x02605cf3 in ?? () #14 0x00000035 in ?? () #15 0x00000000 in ?? () I'm going to compile a new version of the X server with debugging symbols enabled to see if i can get more information.
So, as promised here is the full backtrace: Note1: I compiled with -O0 -g this time (if it is useful) Note2: It seems that neither of the three times the crash happend doing the same things, however it seems that the crash always happends at the same point in the code (at least i think so). Eventhough it doesn't happend at the same point the longest time it has been up has been less than 1 minute. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7b106f0 (LWP 3343)] texture_override (ctx=0x854a680, texUnit=0x8555368, enableBits=16, texObj=0x0, textureBit=16) at main/texstate.c:2824 2824 if (!texObj->_Complete) { (gdb) bt #0 texture_override (ctx=0x854a680, texUnit=0x8555368, enableBits=16, texObj=0x0, textureBit=16) at main/texstate.c:2824 #1 0xb2e3a6a2 in _mesa_update_texture (ctx=0x854a680, new_state=4456448) at main/texstate.c:2919 #2 0xb2e228a8 in _mesa_update_state_locked (ctx=0x854a680) at main/state.c:1187 #3 0xb2e22d56 in _mesa_update_state (ctx=0x854a680) at main/state.c:1264 #4 0xb2f031ac in _mesa_GetIntegerv (pname=34038, params=0xbfe4d9bc) at main/get.c:3741 #5 0xb7ace82b in __glXDRIbindTexImage (baseContext=0x8453a00, buffer=8414, glxPixmap=0x8acff58) at glxdri.c:357 #6 0xb7a89b0f in __glXDisp_BindTexImageEXT (cl=0x84d8d2c, pc=0x84f6aa8 "85`\002X ") at glxcmds.c:1530 #7 0xb7a8b22c in __glXDisp_VendorPrivate (cl=0x84d8d2c, pc=0x84f6a9c "\234\020\006") at glxcmds.c:2245 #8 0xb7a900fe in __glXDispatch (client=0x8527e78) at glxext.c:492 #9 0x080872c1 in Dispatch () at dispatch.c:468 #10 0x0806f438 in main (argc=9, argv=0xbfe4dc14, envp=0xbfe4dc3c) at #main.c:448 Here is the information on the Xorg.0.log.old file: Backtrace: 0: /usr/bin/X [0x80d8fe9] 1: /usr/bin/X(xf86SigHandler+0xa3) [0x80d8f95] 2: [0xb7fb2420] 3: /usr/lib/dri/r300_dri.so(_mesa_update_texture+0x292) [0xb2e3a6a2] 4: /usr/lib/dri/r300_dri.so(_mesa_update_state_locked+0x148) [0xb2e228a8] 5: /usr/lib/dri/r300_dri.so(_mesa_update_state+0x2a) [0xb2e22d56] 6: /usr/lib/dri/r300_dri.so(_mesa_GetIntegerv+0x76) [0xb2f031ac] 7: /usr/lib/xorg/modules/extensions//libglx.so [0xb7ace82b] 8: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a89b0f] 9: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a8b22c] 10: /usr/lib/xorg/modules/extensions//libglx.so [0xb7a900fe] 11: /usr/bin/X(Dispatch+0x23a) [0x80872c1] 12: /usr/bin/X(main+0x6f4) [0x806f438] 13: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7bb8450] 14: /usr/bin/X(FontFileCompleteXLFD+0x1f5) [0x806eca1]
The texture object ptr should never be null at that point. It would be interesting to see the texUnit state (with "print *texUnit") at the crash point.
Here is the information requested: Program received signal SIGSEGV, Segmentation fault. texture_override (ctx=0x86b9530, texUnit=0x86c4218, enableBits=16, texObj=0x0, textureBit=16) at main/texstate.c:2824 2824 if (!texObj->_Complete) { (gdb) print *texUnit $1 = {Enabled = 16, _ReallyEnabled = 0, EnvMode = 7681, EnvColor = {0, 0, 0, 0}, TexGenEnabled = 0, GenModeS = 9216, GenModeT = 9216, GenModeR = 9216, GenModeQ = 9216, _GenBitS = 4, _GenBitT = 4, _GenBitR = 4, _GenBitQ = 4, _GenFlags = 0, ObjectPlaneS = {1, 0, 0, 0}, ObjectPlaneT = {0, 1, 0, 0}, ObjectPlaneR = {0, 0, 0, 0}, ObjectPlaneQ = {0, 0, 0, 0}, EyePlaneS = {1, 0, 0, 0}, EyePlaneT = {0, 1, 0, 0}, EyePlaneR = {0, 0, 0, 0}, EyePlaneQ = {0, 0, 0, 0}, LodBias = 0, Combine = {ModeRGB = 8448, ModeA = 8448, SourceRGB = {5890, 34168, 34166}, SourceA = {5890, 34168, 34166}, OperandRGB = {768, 768, 770}, OperandA = {770, 770, 770}, ScaleShiftRGB = 0, ScaleShiftA = 0, _NumArgsRGB = 2, _NumArgsA = 2}, _EnvMode = {ModeRGB = 7681, ModeA = 7681, SourceRGB = {5890, 34168, 34166}, SourceA = {5890, 34168, 34166}, OperandRGB = {768, 768, 770}, OperandA = { 770, 770, 770}, ScaleShiftRGB = 0, ScaleShiftA = 0, _NumArgsRGB = 1, _NumArgsA = 1}, _CurrentCombine = 0x86c4328, Current1D = 0x84570d0, Current2D = 0x8557558, Current3D = 0x8559b50, CurrentCubeMap = 0x868cec0, CurrentRect = 0x0, Current1DArray = 0x8505000, Current2DArray = 0x84e14a8, _Current = 0x0, ColorTable = {InternalFormat = 0, _BaseFormat = 0, Size = 0, TableF = 0x0, TableUB = 0x0, RedSize = 0 '\0', GreenSize = 0 '\0', BlueSize = 0 '\0', AlphaSize = 0 '\0', LuminanceSize = 0 '\0', IntensitySize = 0 '\0'}, ProxyColorTable = {InternalFormat = 0, _BaseFormat = 0, Size = 0, TableF = 0x0, TableUB = 0x0, RedSize = 0 '\0', GreenSize = 0 '\0', BlueSize = 0 '\0', AlphaSize = 0 '\0', LuminanceSize = 0 '\0', IntensitySize = 0 '\0'}, ColorTableEnabled = 0 '\0'} (gdb)
Let's try a new assertion: diff --git a/src/mesa/main/texobj.c b/src/mesa/main/texobj.c index 3e017c1..c24e0c1 100644 --- a/src/mesa/main/texobj.c +++ b/src/mesa/main/texobj.c @@ -291,6 +291,7 @@ _mesa_reference_texobj(struct gl_texture_object **ptr, } assert(!*ptr); + assert(tex); if (tex) { /* reference new texture */ assert(valid_texture_object(tex)); Can you build/test with this change? If this assertion fails, please provide the stack trace.
So, right now i'm seeing X crashing or aborting, in the X.org.log file i see a line at the end of the file that shows the assertion: X: main/texobj.c:294: _mesa_reference_texobj: Assertion `tex' failed. Tomorrow i will be able to attach the debugger and see whether it is a crash or the X server aborting when it reaches the asserting. If it is the latter i would say that the X server should not abort ... in the worst case it should fail "graciosly".
So, after changing the suggested line, and connecting gdb this is where gdb stops: Program received signal SIGABRT, Aborted. 0xb7f32410 in __kernel_vsyscall () (gdb) bt #0 0xb7f32410 in __kernel_vsyscall () #1 0xb7b4cf15 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7b4e891 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb7b460ee in __assert_fail () from /lib/i686/cmov/libc.so.6 #4 0xb2db7d10 in _mesa_reference_texobj (ptr=0xbfe20bf8, tex=0x0) at main/texobj.c:294 #5 0xb2db921e in _mesa_DeleteTextures (n=1, textures=0x8451df8) at main/texobj.c:803 #6 0xb7a16fe9 in __glXDisp_DeleteTextures (cl=0x8adcfac, pc=0x8451df4 "\001") at indirect_dispatch.c:2848 #7 0xb7a100fe in __glXDispatch (client=0x8d7ac18) at glxext.c:492 #8 0x080872c1 in Dispatch () at dispatch.c:468 #9 0x0806f438 in main (argc=9, argv=0xbfe20dc4, envp=0xbfe20dec) at main.c:448 (gdb) cont Continuing. It is an abort which is probably because of the assertion that you told me to put in there.
I have compiled the code from GIT today (drm library and driver, mesa, xserver and xf86-video-ati). This bug is there still, same backtrace. If you need any more information that i can provide so that the bug gets fixed just ask for it and i will do my best to provide it.
Ok, so i tried it once again. I don't know what you did but after one year trying compiz is running perfectly ... 3d applications run quite slow (glxgears went from 2600 fps to barely 400 fps when running in compiz) But the composited desktop runs just perfectly! Thank you very much to the whole team!! Keep up the good work. PD: the version that i'm running if you are interested is from one week and a half ago, it is the whole set: mesa, xserver and xf86-video-ati (the drm module i'm using is the one that came with the 2.6.25 kernel unmodified). Thanks again!
You're running xserver/mesa from git and compiz runs? You're not experiencing #15641? Interesting. (In reply to comment #15) > Ok, so i tried it once again. > > I don't know what you did but after one year trying compiz is running perfectly > ... 3d applications run quite slow (glxgears went from 2600 fps to barely 400 > fps when running in compiz) But the composited desktop runs just perfectly! > > Thank you very much to the whole team!! > Keep up the good work. > > PD: the version that i'm running if you are interested is from one week and a > half ago, it is the whole set: mesa, xserver and xf86-video-ati (the drm module > i'm using is the one that came with the 2.6.25 kernel unmodified). > > Thanks again! >
(In reply to comment #16) > You're running xserver/mesa from git and compiz runs? You're not experiencing > #15641? Interesting. I'm running git pixman/drm/mesa/xserver/xorg-video-ati from today, and both nexuiz and compiz work fine here.
What is the status of this? Is this still seen in current git master?
Resolving as fixed per submitter's comment #15.
Mass version move, cvs -> git
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.