X_GLXMakeCurrent:GLXBadDrawable - Minefield crashed during Ogg Theora playback

RESOLVED WORKSFORME

Status

()

Core
Audio/Video
--
critical
RESOLVED WORKSFORME
8 years ago
8 years ago

People

(Reporter: Markus Popp, Unassigned)

Tracking

unspecified
x86_64
Linux
Points:
---

Firefox Tracking Flags

(blocking2.0 final+)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 3

8 years ago
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: ? → -
(Reporter)

Comment 5

8 years ago
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).
(Reporter)

Comment 6

8 years ago
Created attachment 472293 [details]
Attachment as mentioned in Comment 5
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.
(Reporter)

Comment 8

8 years ago
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.
(Reporter)

Comment 10

8 years ago
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.
(Reporter)

Comment 11

8 years ago
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
blocking2.0: - → ?
(Reporter)

Comment 13

8 years ago
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.
(Reporter)

Comment 15

8 years ago
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.