Bug 38312 - Swrast doesn't really know whether a Framebuffer object is bound
Summary: Swrast doesn't really know whether a Framebuffer object is bound
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/swrast (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2011-06-14 12:32 UTC by Benoit Jacob
Modified: 2018-04-13 11:38 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
firefox.bin.trace (1.15 KB, application/octet-stream)
2011-06-15 08:08 UTC, Tony Mechelynck
Details
firefox-bin.1.trace (10.87 KB, application/octet-stream)
2011-06-15 08:10 UTC, Tony Mechelynck
Details
minefield.log (29.74 KB, text/plain)
2011-06-15 08:11 UTC, Tony Mechelynck
Details
minefield.log.bz2 (no crash at the end) (4.27 KB, application/octet-stream)
2011-06-15 14:05 UTC, Tony Mechelynck
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benoit Jacob 2011-06-14 12:32:52 UTC
This comes from https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c64

This seems to be a swrast bug, but I didn't find the bugzilla component for it.

I have code like this:

glBindFramebuffer(...some arguments...);
glFramebufferRenderbuffer(...some arguments...);
GLenum error = glGetError();
if (error != GL_NO_ERROR)
  exit(1);
// no GL error at this point
GLint framebuffer;
glGetIntegerv(LOCAL_GL_FRAMEBUFFER_BINDING, &framebuffer);
if (!framebuffer)
  printf("WTF???\n");

The bug is that the WTF line is reached. Since glBindFramebuffer and glFramebufferRenderbuffer succeeded, for sure we have a FBO bound. So it's a bug that glGetIntegerv(LOCAL_GL_FRAMEBUFFER_BINDING, &result) returns 0.

This is only confirmed with the swrast driver.
Comment 1 Benoit Jacob 2011-06-14 12:35:21 UTC
Here's some info from the user who reported the bug to us:

OS: openSUSE Linux 11.4 (version: Final, architecture: x86_64)

Software packages (among others, of course):
xorg-x11-driver-video 7.6-53.58.1 ("intel" driver in service)
Mesa 7.10.2-7.3.1
DirectFB-Mesa 1.4.5-14.2

Hardware devices (among others, of course):
Motherboard: Intel/Fujitsu Scenic W620 (handling display, network, PCI)
Framebuffer Device: Intel(r)915G/915GV/910GL Graphics Controller
Comment 2 Benoit Jacob 2011-06-14 12:37:44 UTC
...and, in case you wonder what LOCAL_GL_FRAMEBUFFER_BINDING is, it's just the same as GL_FRAMEBUFFER_BINDING, i forgot to edit that part. It's defined as 0x8CA6 which is the correct value.
Comment 3 Ian Romanick 2011-06-14 12:45:41 UTC
(In reply to comment #0)
> This comes from https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c64
> 
> This seems to be a swrast bug, but I didn't find the bugzilla component for it.
> 
> I have code like this:
> 
> glBindFramebuffer(...some arguments...);
> glFramebufferRenderbuffer(...some arguments...);
> GLenum error = glGetError();
> if (error != GL_NO_ERROR)
>   exit(1);
> // no GL error at this point
> GLint framebuffer;
> glGetIntegerv(LOCAL_GL_FRAMEBUFFER_BINDING, &framebuffer);
> if (!framebuffer)
>   printf("WTF???\n");
> 
> The bug is that the WTF line is reached. Since glBindFramebuffer and
> glFramebufferRenderbuffer succeeded, for sure we have a FBO bound. So it's a
> bug that glGetIntegerv(LOCAL_GL_FRAMEBUFFER_BINDING, &result) returns 0.

Questions:

1. In the 'if (!framebuffer)' case, is there a GL error?

2. If you initialize framebuffer to, say, 0xDEADBEEF before calling glGetIntegerv, is it still 0 after?

3. Does this still happen with more recent bits?  Mesa 7.10.3 was released yesterday.
Comment 4 Benoit Jacob 2011-06-14 13:17:06 UTC
> Questions:

I don't know the answers to these questions. I'll check if the user who reported this is interested in further debugging this and I'll make him a build.

From your perspective, how important are swrast bugs? I've been told that swrast is getting replaced by other software renderers, "llvmpipe" and "softpipe".
Comment 5 Benoit Jacob 2011-06-14 13:28:02 UTC
Also, I forgot something in my pseudocode: we call glCheckFramebufferStatus right before the glGetIntegerv call. This shouldn't make any difference, but it could hit a bug whereby glCheckFramebufferStatus resets the framebuffer binding.
Comment 6 Ian Romanick 2011-06-14 15:19:19 UTC
(In reply to comment #4)
> > Questions:
> 
> I don't know the answers to these questions. I'll check if the user who
> reported this is interested in further debugging this and I'll make him a
> build.
> 
> From your perspective, how important are swrast bugs? I've been told that
> swrast is getting replaced by other software renderers, "llvmpipe" and
> "softpipe".

Most of this code is used by all Mesa drivers.  From one of the posts (https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c65) in the Mozilla bug, it looked like it should use the i915 driver instead of swrast anyway.  An earlier post (https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c56) even suggests r600.  It's a little confusing.

I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html) could capture a trace for Mesa developers to replay...
Comment 7 Karl Tomlinson 2011-06-14 23:09:11 UTC
Yes, sorry, there are probably a few confounding issues in the one bug report.

Refer to https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c3 for glxinfo in the configuration involved here.
Comment 8 Tony Mechelynck 2011-06-15 05:40:10 UTC
(In reply to comment #4)
> > Questions:
> 
> I don't know the answers to these questions. I'll check if the user who
> reported this is interested in further debugging this and I'll make him a
> build.
[...]

Yes I am, even if my "usual" browser doesn't crash at closedown anymore: a crash is a crash, and if t isn't fixed it will happen again.

I just uploaded a new log, see https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c74

(In reply to comment #3)
[...]
> 3. Does this still happen with more recent bits?  Mesa 7.10.3 was released
> yesterday.

I don't know, I'm at the mercy of openSUSE Linux for all my software except Firefox and SeaMonkey (which I get from Mozilla), their extensions (which I get mostly from addons.mozilla.org) and Vim (which I compile from Bram Moolenaar's latest sources).
Comment 9 Benoit Jacob 2011-06-15 05:42:32 UTC
(In reply to comment #3)
> Questions:
> 
> 1. In the 'if (!framebuffer)' case, is there a GL error?
> 
> 2. If you initialize framebuffer to, say, 0xDEADBEEF before calling
> glGetIntegerv, is it still 0 after?

I made a build initializing as you suggest and logging the GetIntegerv call. Resulting log:
https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c74

Relevant part:

framebuffer info:
[gl:0x197d3f0] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000]
  default framebuffer. No FBO is currently bound.

That means that GetIntegerv did not generate any error (the [0x0000]) and really did set the result to 0 (did not just leave it uninitialized).
Comment 10 Benoit Jacob 2011-06-15 05:59:49 UTC
(In reply to comment #6)
> I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html) could
> capture a trace for Mesa developers to replay...

I heard about it but how easy is that for me to deploy in a custom debugging build for a user to run? Meanwhile, I have logs with a verbose GL debug mode that we have. While (as I mention above) it doesn't have some GL calls made from the debugging layer itself, the bug is known to exist already without the debugging layer, so that shouldn't matter. Relevant part of the log below. the gl:0x197d3f0 part is the pointer to the GLContext object, it means all these calls are on the same GL context (this is really checked). The > is before the GL call, the < is after. The [0x0000] is the GL error code, so that means GL_NO_ERROR. For some GL functions, the parameters values are printed. It's enough to reconstruct what we've been doing here: I've added comments.

/* Create and bind a texture, name=1 */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fGenTextures(GLsizei, GLuint*)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fGenTextures(GLsizei, GLuint*) [0x0000]
[gl:0x197d3f0] > void mozilla::gl::GLContext::fBindTexture(GLenum, GLuint)
parameters:
  target = 0x0de1
  texture = 1
[gl:0x197d3f0] < void mozilla::gl::GLContext::fBindTexture(GLenum, GLuint) [0x0000]

/* Set some texparameters */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fTexParameteri(GLenum, GLenum, GLint)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fTexParameteri(GLenum, GLenum, GLint) [0x0000]
[gl:0x197d3f0] > void mozilla::gl::GLContext::fTexParameteri(GLenum, GLenum, GLint)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fTexParameteri(GLenum, GLenum, GLint) [0x0000]

/* Create and bind a framebuffer. Note that FramebufferTexture2D call below succeeds, meaning that we really have a non-default framebuffer bound. */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fGenFramebuffers(GLsizei, GLuint*)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fGenFramebuffers(GLsizei, GLuint*) [0x0000]
[gl:0x197d3f0] > void mozilla::gl::GLContext::fBindFramebuffer(GLenum, GLuint)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fBindFramebuffer(GLenum, GLuint) [0x0000]

/* Create a renderbuffer */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fGenRenderbuffers(GLsizei, GLuint*)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fGenRenderbuffers(GLsizei, GLuint*) [0x0000]

/* Upload an image to our texture. If you're wondering about the 16x16 size, that's because this is a dummy GL context only used to get driver info to print in the about:support page */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fTexImage2D(GLenum, GLint, GLint, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid*)
parameters:
  target = 0x0de1
  level = 0
  width = 16
 height = 16
  format = 0x1908
, type = 0x1401
[gl:0x197d3f0] < void mozilla::gl::GLContext::fTexImage2D(GLenum, GLint, GLint, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid*) [0x0000]

/* Bind our renderbuffer and allocate it as a depth buffer
 * GL_DEPTH_COMPONENT24 == 0x81A6
 */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fBindRenderbuffer(GLenum, GLuint)
parameters:
  target = 0x8d41
  renderbuffer = 1
[gl:0x197d3f0] < void mozilla::gl::GLContext::fBindRenderbuffer(GLenum, GLuint) [0x0000]
[gl:0x197d3f0] > void mozilla::gl::GLContext::fRenderbufferStorage(GLenum, GLenum, GLsizei, GLsizei)
parameters:
  target = 0x8d41
  internalFormat = 0x81a6
  width = 16
  height = 16
[gl:0x197d3f0] < void mozilla::gl::GLContext::fRenderbufferStorage(GLenum, GLenum, GLsizei, GLsizei) [0x0000]

/* Attach our texture to the color attachment point, and our renderbuffer to
 * the depth attachment point
 * GL_COLOR_ATTACHMENT0 == 0x8CE0
 * GL_DEPTH_ATTACHMENT == 0x8D00
 */

[gl:0x197d3f0] > void mozilla::gl::GLContext::fFramebufferTexture2D(GLenum, GLenum, GLenum, GLuint, GLint)
parameters:
  attachmentPoint = 0x8ce0
  texture = 1
  level = 0
[gl:0x197d3f0] < void mozilla::gl::GLContext::fFramebufferTexture2D(GLenum, GLenum, GLenum, GLuint, GLint) [0x0000]
[gl:0x197d3f0] > void mozilla::gl::GLContext::fFramebufferRenderbuffer(GLenum, GLenum, GLenum, GLuint)
parameters:
  attachmentPoint = 0x8d00
  renderbuffer = 1
[gl:0x197d3f0] < void mozilla::gl::GLContext::fFramebufferRenderbuffer(GLenum, GLenum, GLenum, GLuint) [0x0000]

/* Check FB status and FB binding */

[gl:0x197d3f0] > GLenum mozilla::gl::GLContext::fCheckFramebufferStatus(GLenum)
[gl:0x197d3f0] < GLenum mozilla::gl::GLContext::fCheckFramebufferStatus(GLenum) [0x0000]
framebuffer info:
[gl:0x197d3f0] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*)
[gl:0x197d3f0] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000]

/* Boom: getIntegerv(GL_FRAMEBUFFER_BINDING, &result) explicitly set the
 * result to 0, despite above FramebufferRenderbuffer call succeeding
 */

  default framebuffer. No FBO is currently bound.
WARNING: Error resizing offscreen framebuffer -- framebuffer not complete: file /builds/slave/try-lnx64-dbg/build/gfx/thebes/GLContext.cpp, line 877
Comment 11 Benoit Jacob 2011-06-15 06:02:58 UTC
How easy would it be for me to try swrast? I'm using Debian Testing, but with the NVIDIA driver.
Comment 12 Brian Paul 2011-06-15 06:09:43 UTC
(In reply to comment #10)
> (In reply to comment #6)
> > I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html) could
> > capture a trace for Mesa developers to replay...
> 
> I heard about it but how easy is that for me to deploy in a custom debugging
> build for a user to run?

It should only take 10 minutes to grab apitrace, compile it and try capturing a trace.  It would be super helpful to us.  And in the future, it would be the best way to report bugs.  The only problem at this point might be multi-context handling.

http://code.google.com/p/jrfonseca/downloads/detail?name=apitrace-20101109.zip
Comment 13 Jose Fonseca 2011-06-15 06:24:33 UTC
(In reply to comment #12)
> (In reply to comment #10)
> > (In reply to comment #6)
> > > I wonder if apitrace (http://zrusin.blogspot.com/2011/04/apitrace.html) could
> > > capture a trace for Mesa developers to replay...
> > 
> > I heard about it but how easy is that for me to deploy in a custom debugging
> > build for a user to run?
> 
> It should only take 10 minutes to grab apitrace, compile it and try capturing a
> trace.  It would be super helpful to us.  And in the future, it would be the
> best way to report bugs.  The only problem at this point might be multi-context
> handling.
> 
> http://code.google.com/p/jrfonseca/downloads/detail?name=apitrace-20101109.zip

This zip file contains old windows binaries.

But tracing is really simple. Just do:

  git clone https://github.com/apitrace/apitrace.git
  cmake .
  make
  LD_PRELOAD=$PWD/glxtrace.so /path/to/firefox

and firefox*.trace will be generated.
Comment 14 Brian Paul 2011-06-15 06:29:08 UTC
Between the call to glBindFramebuffer() and glGetIntegerv(GL_FRAMEBUFFER_BINDING) are you calling glXMakeCurrent()?  That would change the context's framebuffer binding.  We might have that wrong, actually...
Comment 15 Benoit Jacob 2011-06-15 06:36:53 UTC
(In reply to comment #14)
> Between the call to glBindFramebuffer() and
> glGetIntegerv(GL_FRAMEBUFFER_BINDING) are you calling glXMakeCurrent()?

As far as I can see, no, we don't call glXMakeCurrent between these two points.

> That
> would change the context's framebuffer binding.  We might have that wrong,
> actually...

Why would glXMakeCurrent change GL state?
Comment 16 Benoit Jacob 2011-06-15 06:43:14 UTC
Tony, if you have time, could you please try running firefox with apitrace as explained in comment 13?

Note: you'll need to install cmake and you'll need to cd to the apitrace directory you just cloned before running cmake.

Please use a debug build of Firefox for that, for example the latest build I made for you, as we need to see where that "WARNING: Error resizing offscreen framebuffer -- framebuffer not complete" was printed and it's only printed in debug builds. Please keep MOZ_X_SYNC=1 but no need for MOZ_GL_DEBUG_VERBOSE=1 as apitrace replaces that.
Comment 17 Brian Paul 2011-06-15 07:02:31 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > Between the call to glBindFramebuffer() and
> > glGetIntegerv(GL_FRAMEBUFFER_BINDING) are you calling glXMakeCurrent()?
> 
> As far as I can see, no, we don't call glXMakeCurrent between these two points.

OK.


> > That
> > would change the context's framebuffer binding.  We might have that wrong,
> > actually...
> 
> Why would glXMakeCurrent change GL state?

glXMakeCurrent creates a binding between a rendering context and a surface for drawing.  The surface (an X Window or GLXPixmaps) is internally represented by an FBO.  Window system FBOs like that and user-created FBOs are pretty much the same with only minor differences in how they're handled.  In any case, the context has "current FBO" pointers that are set in glXMakeCurrent().  That's a potential state change.

The GL_ARB/EXT_framebuffer_object extensions say that calling glXMakeCurrent() should not change the current read/draw FBO bindings if the context is currently pointing at user-created FBOs.  I needed to check Mesa to be sure that we weren't inadvertently binding the X window FBO at in this situation.  It looks like we're doing the right thing.  I just wrote a new piglit test to verify this fact.

Anyway, I don't think this is the issue.  Perhaps you could sprinkle more glGetIntegerv(GL_FRAMEBUFFER_BINDING, &x) calls between the glBindFramebuffer() call and the failure point.
Comment 18 Tony Mechelynck 2011-06-15 08:08:45 UTC
Created attachment 48001 [details]
firefox.bin.trace
Comment 19 Tony Mechelynck 2011-06-15 08:10:04 UTC
Created attachment 48002 [details]
firefox-bin.1.trace
Comment 20 Tony Mechelynck 2011-06-15 08:11:48 UTC
Created attachment 48003 [details]
minefield.log
Comment 21 Jose Fonseca 2011-06-15 08:19:16 UTC
It looks like firefox is trying to destroy the currently bound context:

$ tracedump firefox-bin.1.trace  | grep ctx
17 glXMakeCurrent(dpy = 0x62ea00, drawable = 125830043, ctx = 0x29b15e0) = True
173 glXMakeCurrent(dpy = 0x62ea00, drawable = 125830041, ctx = 0x29b4f20) = True
351 glXDestroyContext(dpy = 0x62ea00, ctx = 0x29b4f20)
warning: incomplete call glXMakeCurrent
354 glXMakeCurrent(dpy = 0x62ea00, drawable = 125830043, ctx = 0x29b15e0)

According to glXDestroyContext's documentation, the context destruction should be deferred until it's no longer current to any thread.
Comment 22 Tony Mechelynck 2011-06-15 08:21:35 UTC
(In reply to comment #16)
> Tony, if you have time, could you please try running firefox with apitrace as
> explained in comment 13?
> 
> Note: you'll need to install cmake and you'll need to cd to the apitrace
> directory you just cloned before running cmake.
> 
> Please use a debug build of Firefox for that, for example the latest build I
> made for you, as we need to see where that "WARNING: Error resizing offscreen
> framebuffer -- framebuffer not complete" was printed and it's only printed in
> debug builds. Please keep MOZ_X_SYNC=1 but no need for MOZ_GL_DEBUG_VERBOSE=1
> as apitrace replaces that.

(In reply to comment #13)
[...]
>   git clone https://github.com/apitrace/apitrace.git
>   cmake .
>   make
>   LD_PRELOAD=$PWD/glxtrace.so /path/to/firefox
> 
> and firefox*.trace will be generated.

cmake 2.8.3-5.2 is already installed
git clone... cmake... make... done
LD_PRELOAD=$PWD/glxtrace.so MOZ_X_SYNC=1 ~/Minefield/firefox/firefox --sync -P virgin -no-remote 2>&1|tee ~/Minefield/minefield.log
...firefox opens
...look at a few tabs, they seem normal
...Ctrl+Q
...Breakpad comes up, a little comment, [ Quit Firefox ]
ls -l *.trace
-rw-r--r-- 1 root root 11131 Jun 15 16:53 firefox-bin.1.trace
-rw-r--r-- 1 root root  1179 Jun 15 16:50 firefox-bin.trace
ls -l ~/Minefield/minefield.log
-rw-r--r-- 1 root root 30450 Jun 15 16:53 minefield.log
ls -l ~/.mozilla/firefox/Crash\ Reports/submitted
...the oldest one is:
-rw-r--r-- 1 root root  50 Jun 15 16:53 bp-47314ac3-428f-4bab-af98-b88c12110615.txt
meaning that more info about the crash will be found at https://crash-stats.mozilla.com/report/index/47314ac3-428f-4bab-af98-b88c12110615
Comment 23 Benoit Jacob 2011-06-15 08:27:16 UTC
(In reply to comment #21)
> According to glXDestroyContext's documentation, the context destruction should
> be deferred until it's no longer current to any thread.

Oh, I didn't know that. Indeed we are calling glXDestroyContext with the GL context current on main thread. Build coming with this fixed.

(In reply to comment #17)
> Anyway, I don't think this is the issue.  Perhaps you could sprinkle more
> glGetIntegerv(GL_FRAMEBUFFER_BINDING, &x) calls between the glBindFramebuffer()
> call and the failure point.

Build coming with a glGetIntegerv(GL_FRAMEBUFFER_BINDING, &x) logged before and after every GL call.
Comment 24 Jose Fonseca 2011-06-15 08:43:18 UTC
(In reply to comment #23)
> (In reply to comment #21)
> > According to glXDestroyContext's documentation, the context destruction should
> > be deferred until it's no longer current to any thread.
> 
> Oh, I didn't know that. Indeed we are calling glXDestroyContext with the GL
> context current on main thread. Build coming with this fixed.

Sorry, I was ambiguous. It's the GL driver's responsibility to defer the destruction internally. See:

  http://www.opengl.org/sdk/docs/man/xhtml/glXDestroyContext.xml

I couldn't find a piglit test for this yet.

That said, it's probably easy to work around this on firefox, until Mesa handles this correctly.  Assuming this is indeed the problem.
Comment 25 Benoit Jacob 2011-06-15 08:49:01 UTC
New tryserver build: http://tbpl.mozilla.org/?tree=Try&rev=2a3c576f5adf
When the builds are done they will be available at:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-2a3c576f5adf

This build has the changes mentioned in comment 23: it releases the GL context before destroying it, it logs MakeCurrent call and it constantly logs the FBO binding. Please run like this:

MOZ_GL_DEBUG_VERBOSE=1 MOZ_X_SYNC=1 ./firefox -P -no-remote 2>&1 | tee logfile.txt

You can add -P -no-remote if you already have a Firefox session open. Please attach the logfile and report on whether this build still crashes on closedown.
Comment 26 Benoit Jacob 2011-06-15 08:52:59 UTC
(In reply to comment #24)
> Sorry, I was ambiguous. It's the GL driver's responsibility to defer the
> destruction internally. See:
> 
>   http://www.opengl.org/sdk/docs/man/xhtml/glXDestroyContext.xml
> 
> I couldn't find a piglit test for this yet.
> 
> That said, it's probably easy to work around this on firefox, until Mesa
> handles this correctly.  Assuming this is indeed the problem.

Oh, that's even more interesting to me. Our code was:

        glXDestroyContext(mDisplay, mContext);
        glXDestroyPixmap(mDisplay, mDrawable);

We had X errors from MakeCurrent() on closedown suggesting that the X drawable had been destroyed too early. Now it seems that it could just be that since the context was still current, its destruction was postponed, so by the time it actually happened, the drawable has already been destroyed. If that's the case, my latest build should not crash on closedown.
Comment 27 Tony Mechelynck 2011-06-15 14:05:39 UTC
Created attachment 48014 [details]
minefield.log.bz2 (no crash at the end)

(In reply to comment #25)
> New tryserver build: http://tbpl.mozilla.org/?tree=Try&rev=2a3c576f5adf
> When the builds are done they will be available at:
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bjacob@mozilla.com-2a3c576f5adf
> 
> This build has the changes mentioned in comment 23: it releases the GL context
> before destroying it, it logs MakeCurrent call and it constantly logs the FBO
> binding. Please run like this:
> 
> MOZ_GL_DEBUG_VERBOSE=1 MOZ_X_SYNC=1 ./firefox -P -no-remote 2>&1 | tee
> logfile.txt

I used --sync -P virgin -no-remote because it was easier for me to get the command-line from bash history in a konsole tab dedicated to the present tests and (once a day) fetching the next round of nightlies.

> 
> You can add -P -no-remote if you already have a Firefox session open. Please
> attach the logfile and report on whether this build still crashes on closedown.

No crash on closedown.
Comment 28 Benoit Jacob 2011-06-15 14:12:39 UTC
(In reply to comment #27)
> Created an attachment (id=48014) [details]
> minefield.log.bz2 (no crash at the end)

Thanks a lot!

The log shows that glGetIntegerv(FRAMEBUFFER_BINDING, &result) always returns 0. Even right after glBindFramebuffer called with a value just returned by glGenFramebuffers. Even when a glFramebufferRenderbuffer call succeeds, which is incompatible with the FB binding being 0.

> No crash on closedown.

\o/ !!!
Comment 29 Benoit Jacob 2011-06-15 14:13:32 UTC
Also the log shows that glXMakeCurrent is not called between the two points in question.
Comment 30 Benoit Jacob 2011-06-15 14:14:21 UTC
Note that with the NVIDIA driver, nonzero FB bindings are correctly reported by this build.
Comment 31 Brian Paul 2011-06-15 14:25:18 UTC
(In reply to comment #28)
> (In reply to comment #27)
> > Created an attachment (id=48014) [details] [details]
> > minefield.log.bz2 (no crash at the end)
> 
> Thanks a lot!
> 
> The log shows that glGetIntegerv(FRAMEBUFFER_BINDING, &result) always returns
> 0. Even right after glBindFramebuffer called with a value just returned by
> glGenFramebuffers. Even when a glFramebufferRenderbuffer call succeeds, which
> is incompatible with the FB binding being 0.

I just hacked a piglit fbo test to query GL_FRAMEBUFFER_BINDING after glBindFramebuffer() and assert that the value returned matches the bind call.  It works fine here.  I don't know what's going on in your test.  Which version of Mesa are you using?
Comment 32 Benoit Jacob 2011-06-15 14:28:44 UTC
(In reply to comment #31)
> I just hacked a piglit fbo test to query GL_FRAMEBUFFER_BINDING after
> glBindFramebuffer() and assert that the value returned matches the bind call. 
> It works fine here.  I don't know what's going on in your test.  Which version
> of Mesa are you using?

See comment 1, Tony is using Mesa 7.10.2.
Comment 33 Benoit Jacob 2011-06-15 14:31:23 UTC
Anyway, since the crash is fixed, we don't have anymore a reason to blacklist. Firefox just recognizes at runtime when the bug occurs and fails the WebGL context creation.
Comment 34 Tony Mechelynck 2011-06-15 14:46:19 UTC
(In reply to comment #32)
> (In reply to comment #31)
> > I just hacked a piglit fbo test to query GL_FRAMEBUFFER_BINDING after
> > glBindFramebuffer() and assert that the value returned matches the bind call. 
> > It works fine here.  I don't know what's going on in your test.  Which version
> > of Mesa are you using?
> 
> See comment 1, Tony is using Mesa 7.10.2.

and (see comment #8 /in fine/) it's the newest version I can use until or unless openSUSE decides to distribute an upgraded version. If necessary, a bug can be opened at bugzilla.novell.com if the Mesa 7.10.3 is found to fix a possible crash (let's say in firefox-aurora). IIUC the liaison officer between Mozilla and SuSE is Wolfgang Rosenauer. I don't know if he's registered at bugs.freedesktop.org.
Comment 35 Tony Mechelynck 2018-04-13 11:38:35 UTC
FWIW, the Mozilla bug mentioned in comment #1 was VERIFIED FIXED 2011-06-17 in https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c88 (Firefox 7, then ported to Firefox 6). Some water has passed under the bridge since then. :-)

FWIW again, my current Mesa version is described as shown below. It's been years since I last experienced the bug.

linux-2iyu:~ # rpm -qi Mesa
Name        : Mesa
Version     : 17.0.5
Release     : 176.1
Architecture: x86_64
Install Date: Sun 10 Sep 2017 16:41:26 CEST
Group       : System/Libraries
Size        : 17362987
License     : MIT
Signature   : RSA/SHA256, Wed 06 Sep 2017 14:26:43 CEST, Key ID b88b2fd43dbdc284
Source RPM  : Mesa-17.0.5-176.1.src.rpm
Build Date  : Wed 06 Sep 2017 14:18:59 CEST
Build Host  : cloud126
Relocations : (not relocatable)
Packager    : http://bugs.opensuse.org
Vendor      : openSUSE
URL         : http://www.mesa3d.org
Summary     : System for rendering interactive 3-D graphics
Description :
Mesa is a 3-D graphics library with an API which is very similar to
that of OpenGL.* To the extent that Mesa utilizes the OpenGL command
syntax or state machine, it is being used with authorization from
Silicon Graphics, Inc.(SGI). However, the author does not possess an
OpenGL license from SGI, and makes no claim that Mesa is in any way a
compatible replacement for OpenGL or associated with SGI. Those who
want a licensed implementation of OpenGL should contact a licensed
vendor.

Please do not refer to the library as MesaGL (for legal reasons). It's
just Mesa or The Mesa 3-D graphics library.

* OpenGL is a trademark of Silicon Graphics Incorporated.
Distribution: openSUSE Leap 42.3


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.