User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b5pre) Gecko/20100820 Minefield/4.0b5pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b5pre) Gecko/20100820 Minefield/4.0b5pre Minefield crahsed during Ogg Theora playback, like at http://audio-video.gnu.org/video/.original_files/rms-speech-patents-calgary-20050518-720x480.ogg. Reported through Minefield's bug reporter: http://crash-stats.mozilla.com/report/index/c1164fd3-03e5-4760-9445-b26722100822 Reproducible: Sometimes Steps to Reproduce: 1. go to http://audio-video.gnu.org/video/.original_files/rms-speech-patents-calgary-20050518-720x480.ogg 2. playback video 3. try switching between normal playback and fullscreen playback Actual Results: Minefield crashes Expected Results: Minefield shouldn't crash
Summary: GLXBadDrawable - Minefield crashed during Ogg Theora playback → X_GLXMakeCurrent:GLXBadDrawable - Minefield crashed during Ogg Theora playback
Similar crash reports on Ubuntu (reporter has FC13) with better stack. e.g. bp-2e6a1f0c-31b4-4b32-a055-3c1ba2100820 Both reports have libGL.so.256.44 (though one is x86_64 and other is i686). Where does that libGL.so come from?
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
256.44 is the version number of the latest NVIDIA drivers, and I've got /usr/lib64/nvidia/libGL.so.195.36.31 (and I have the 195.36.31 drivers), so this is almost definitely NVIDIA's libGL.
I have the NVIDIA 256.44 drivers for Linux x86_64/AMD64/EM64T installed, as downloaded at http://www.nvidia.com/object/unix.html During the installation process I got asked whether I want to install the 32bit drivers in addition to the 64bit drivers, which I confirmed. This makes it likely that I have the drivers for both architectures installed, although I don't think the 32bit drivers shouldn't play a role here (but then, who knows?).
Markus, if you could install debuginfo packages for all the libraries in the stack in comment #1, that might help us get a better stack. We'll need more data before we can block on this.
blocking2.0: ? → -
Here is what I have so far: ... a new crash report, running the latest mozilla-central-linux64-debug build: http://crash-stats.mozilla.com/report/index/bp-29a185a1-7dea-4e51-97b1-8000b2100905 My video driver (as downloaded at http://www.nvidia.com/object/linux-display-amd64-256.53-driver.html) is: $ glxinfo | grep OpenGL OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce 8600 GT/PCI/SSE2 OpenGL version string: 3.3.0 NVIDIA 256.53 OpenGL shading language version string: 3.30 NVIDIA via Cg compiler OpenGL extensions: (I updated from 256.44 to 256.53 since the initial bug report, but the crash still occurs) When the crash showed up again, I got this output at the console: ###!!! ABORT: X_GLXMakeCurrent: GLXBadDrawable; id=0x4e037be Re-running with MOZ_X_SYNC=1 in the environment may give a more helpful backtrace.: file /builds/slave/mozilla-central-linux64-debug/build/toolkit/xre/nsX11ErrorHandler.cpp, line 190 UNKNOWN [/opt/minefield-debug/libxul.so +0x006B0CB3] _XError+0x000000F4 [/usr/lib64/libX11.so.6 +0x00046B24] _XReply+0x000001D6 [/usr/lib64/libX11.so.6 +0x0004D6A6] UNKNOWN [/usr/lib64/libGL.so.1 +0x00079368] ###!!! ABORT: X_GLXMakeCurrent: GLXBadDrawable; id=0x4e037be Re-running with MOZ_X_SYNC=1 in the environment may give a more helpful backtrace.: file /builds/slave/mozilla-central-linux64-debug/build/toolkit/xre/nsX11ErrorHandler.cpp, line 190 == I also have some more output which I logged into a file. I don't know if it contains anything useful, but I will attach it here. Also, while playing the video in full screen, the issue which got reported in bug 587098 showed up (glitchy video (theora or webm) in fullscreen mode), which may or may not be related. Please let me know if I can create some more useful output (if so, please point me to instructions how to do so).
An xtrace log might be helpful here: http://xtrace.alioth.debian.org/ Maybe fedora has xtrace packages. I build Debian's 1.1.0 version from here: http://packages.debian.org/sid/xtrace http://ftp.de.debian.org/debian/pool/main/x/xtrace/xtrace_1.1.0.orig.tar.gz (I don't recall much in the debian patch for that.) and run with .../install/bin/xtrace -o output.xtrace minefield Old versions require a two-step, start xtrace as a server and connect approach. The log file will probably be too large to attach here. We probably only need the tail. If you can find the XID in the error event, then search back to the point where the XID was created, we probably don't need much before that. Or if it's easier to just post the whole log on a server somewhere, that's good too. Bug 589546 comment 38 indicates what I'm looking for. It might be helpful to attach the whole output from glxinfo too.
I seem to have xtrace on my system, but it didn't quite work like that: $ xtrace -V xtrace (GNU libc) 2.12 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Ulrich Drepper. $ xtrace -o xtrace.output /opt/minefield-debug/firefox -P test executable `-o' not found Try `xtrace --help' for more information. $ xtrace --help Usage: xtrace [OPTION]... PROGRAM [PROGRAMOPTION]... Trace execution of program by printing currently executed function. --data=FILE Don't run the program, just print the data from FILE. -?,--help Print this help and exit --usage Give a short usage message -V,--version Print version information and exit Mandatory arguments to long options are also mandatory for any corresponding short options. For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. == I also tried to run: xtrace /opt/minefield-debug/firefox -P test > output.xtrace but it only created this output: Function File Line -------------------------------------------------------------------------------- == minefield-debug is this version: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64-debug/1283722694/firefox-4.0b6pre.en-US.linux-x86_64.tar.bz2 Any hints what I could try?
That xtrace is from glibc and although it has the same name, it is quite different. (Don't know exactly what that does.) I can't see any Fedora (X) xtrace package. You might get away with extracting files from a debian binary package from http://packages.debian.org/sid/xtrace Something like dkpg -x package-file.deb output-directory.
Created attachment 472475 [details] My glxinfo output I now also have the output.xtrace file with 40 MB available. I'm still trying to find the position where to copy the relevant part from. If I don't find it, maybe it's best if I just gzip and upload it to my server and you can get it from there.
I uploaded the entire xtrace output file, compressed with gzip, so you can download it at http://var.mpopp.net/output.xtrace.gz
Attachment #472293 - Attachment mime type: application/octet-stream → text/plain
Attachment #472475 - Attachment mime type: application/octet-stream → text/plain
Thanks. That's very helpful, Markus. Looks like we are trying to MakeCurrent a context with a window that has been destroyed. The GLXDrawable was a window. (I wonder whether it's common for Window and GLXWindow to have the same id.) It and the context were used successfully several times. This is the last time: > 001:<:9061: 16: GLX-Request(135,5): glXMakeCurrent drawable=0x06e01c3d context=0x06e01c3e old_context_tag=0x00000001 > 001:>:9061:32: Reply to glXMakeCurrent: new_context_tag=0x00000001 > 001:<:9062: 12: NV-GLX-Request(138,33): UNKNOWN opcode=0x8a opcode2=0x21 unparsed-data=0x00,0x00,0x00,0x00,0x22,0x03,0x00,0x00; > 001:>:9062:10936: unexpected Reply: data1=0x01 data2=0xf0 unparsed-data=... > [...] > 001:<:9063:112: NV-GLX-Request(138,12): UNKNOWN opcode=0x8a opcode2=0x0c unparsed-data=0x00,0x00,0x00,0x00,0x22,0x03,0x00,0x00,0x3d,0x1c,0xe0,0x06,... > 001:>:9063:32: unexpected Reply: data1=0x01 data2=0x19 unparsed-data=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x80,0x9d,0x7c,0x00,0x00,0x00,0x00,0x00,0xea,0x00,0xd2,0x4d,0x77,0x7f,0x00,0x00; > 001:<:9064: 12: NV-GLX-Request(138,33): UNKNOWN opcode=0x8a opcode2=0x21 unparsed-data=0x00,0x00,0x00,0x00,0x22,0x03,0x00,0x00; > [...] > 001:>:9064:10936: unexpected Reply: data1=0x01 data2=0xf0 unparsed-data=... > [...] Then the window is destroyed: > 001:<:9065: 8: Request(10): UnmapWindow window=0x06e01c3d > 001:<:9066: 8: Request(4): DestroyWindow window=0x06e01c3d > [...] > 001:>:906c: Event DestroyNotify(17) event=0x06e01c3d window=0x06e01c3d > 001:<:9067: 8: Request(54): FreePixmap drawable=0x06e01c3a > 001:<:9068: 8: Request(54): FreePixmap drawable=0x06e01c3b > 001:<:9069: 8: SYNC-Request(146,6): UNKNOWN opcode=0x92 opcode2=0x06 unparsed-data=0x37,0x1c,0xe0,0x06; Then lots of other things happen, including drawing: > 001:<:16a2e: 36: RENDER-Request(151,8): Composite op=Over(0x03) src=0x06e012df mask=None(0x00000000) dst=0x06e04f43 xSrc=0 ySrc=0 xMask=0 yMask=0 xDst=1652 yDst=4 width=24 height=24 > 001:<:16a2f: 20: Request(73): GetImage format=ZPixmap(0x02) drawable=0x06e04f42 x=0 y=0 width=1680 height=1050 plane-mask=0xffffffff > 001:>:6a2f:7056032: Reply to GetImage: depth=0x20 32-bit values got=1764000 visual=None(0x00000000) > 001:<:16a30: 8: RENDER-Request(151,7): FreePicture picture=0x06e04f43 > 001:<:16a31: 8: Request(54): FreePixmap drawable=0x06e04f42 > 001:<:16a32: 8: Request(54): FreePixmap drawable=0x06e04f41 Some strange pixmap creation and destruction without use: > 001:<:16a33: 16: Request(53): CreatePixmap depth=0x18 pid=0x06e04f4d drawable=0x06e04ce6 width=1680 height=1050 > 001:<:16a34: 8: Request(54): FreePixmap drawable=0x06e04f4d > 001:<:16a35: 16: Request(53): CreatePixmap depth=0x18 pid=0x06e04f4e drawable=0x06e04ce6 width=1680 height=1050 > 001:<:16a36: 8: Request(54): FreePixmap drawable=0x06e04f4e > 001:<:16a37: 16: Request(53): CreatePixmap depth=0x18 pid=0x06e04f4f drawable=0x06e04ce6 width=1680 height=1050 > 001:<:16a38: 8: Request(54): FreePixmap drawable=0x06e04f4f > 001:<:16a39: 16: Request(53): CreatePixmap depth=0x18 pid=0x06e04f50 drawable=0x06e04ce6 width=1680 height=1050 > 001:<:16a3a: 8: Request(54): FreePixmap drawable=0x06e04f50 > 001:<:16a3b: 16: Request(53): CreatePixmap depth=0x18 pid=0x06e04f51 drawable=0x06e04ce6 width=1680 height=1050 > 001:<:16a3c: 8: Request(54): FreePixmap drawable=0x06e04f51 > 001:<:16a3d: 16: Request(53): CreatePixmap depth=0x18 pid=0x06e04f52 drawable=0x06e04ce6 width=1680 height=1050 > 001:<:16a3e: 8: Request(54): FreePixmap drawable=0x06e04f52 > 001:<:16a3f: 16: Request(53): CreatePixmap depth=0x18 pid=0x06e04f53 drawable=0x06e04ce6 width=1680 height=1050 > 001:<:16a40: 8: Request(54): FreePixmap drawable=0x06e04f53 Then another attempt to make the context current with the now-destroyed window. > 001:<:16a41: 16: GLX-Request(135,5): glXMakeCurrent drawable=0x06e01c3d context=0x06e01c3e old_context_tag=0x00000001 > 001:>:6a41:Error 146=GLXBadDrawable: major=135, minor=5, bad=115350589
I'm glad that it helps :). Is it possible that the glitchy video issue reported in bug 587098 is related to these crashes, so that a fix for one issue resolves the other as well?
(In reply to comment #13) > Is it possible that the glitchy video issue reported in bug 587098 is related > to these crashes, so that a fix for one issue resolves the other as well? I doubt it's related.
blocking2.0: ? → final+
I'm not able to reproduce the crash in recent Minefield builds anymore. Something may have fixed it.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.