Re: [Mesa-dev] [PATCH] mesa: Restore NULL context check in _mesa_reference_renderbuffer_().
That's not a false alarm... That's supposed to work! libGL and driver versions are supposed to be independent. Anytime they're not is a bug. On Dec 8, 2012, at 8:43 PM, Kenneth Graunke kenn...@whitecape.org wrote: On 12/08/2012 05:40 AM, Brian Paul wrote: On 12/08/2012 01:10 AM, Kenneth Graunke wrote: Starting KDE on i965 makes the X server die in a fire with the following assertion: X: intel_fbo.c:94: intel_delete_renderbuffer: Assertion `irb' failed. Obviously, this is rather unpleasant. Bisecting revealed that: 006918c0db77e945ac56b15bc64eba502b86d56c is the first bad commit commit 006918c0db77e945ac56b15bc64eba502b86d56c Author: Brian Paulbri...@vmware.com Date: Sat Dec 1 10:52:42 2012 -0700 mesa: remove warning message in _mesa_reference_renderbuffer_() We were warning when there was no current context and we're about to delete a renderbuffer, but that happens fairly often and isn't really a problem. Fixes http://bugs.freedesktop.org/show_bug.cgi?id=57754 Note: This is a candidate for the stable branches. Tested-by: Ian Romanickian.d.roman...@intel.com This commit removed not only the else emit warning block, but the whole NULL check as well. Apparently it's necessary, so put it back. Hi Kenneth, The assertion says the 'irb' is null, but you're checking if the context is null. Off hand, I think a irb==null check is needed in intel_delete_renderbuffer(). Maybe seeing a stack trace would shed more light on where the null irb/ctx is coming from. In any case, if you need to check for ctx==null, please do that in intel_delete_renderbuffer(). The deal is that some (most?) drivers don't need a context handle in order to free a renderbuffer. In the gallium state tracker we use the context to free a piece of context state that's associated with a renderbuffer, but the renderbuffer itself can be freed without a context. Sorry for the headaches this one is causing. -Brian Sorry for the false alarm...this was my fault. Apparently on my system X is loading an older i965_dri.so, but likely a new libGL. The incompatibility between the one-argument intel_delete_renderbuffer and two-argument gl_renderbuffer::Delete caused something stupid to happen...maybe I got the renderbuffer passed as the context, and NULL for the renderbuffer. I put both halves back in sync and everything's fine now. Again, my apologies for the trouble. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Restore NULL context check in _mesa_reference_renderbuffer_().
On 12/08/2012 01:10 AM, Kenneth Graunke wrote: Starting KDE on i965 makes the X server die in a fire with the following assertion: X: intel_fbo.c:94: intel_delete_renderbuffer: Assertion `irb' failed. Obviously, this is rather unpleasant. Bisecting revealed that: 006918c0db77e945ac56b15bc64eba502b86d56c is the first bad commit commit 006918c0db77e945ac56b15bc64eba502b86d56c Author: Brian Paulbri...@vmware.com Date: Sat Dec 1 10:52:42 2012 -0700 mesa: remove warning message in _mesa_reference_renderbuffer_() We were warning when there was no current context and we're about to delete a renderbuffer, but that happens fairly often and isn't really a problem. Fixes http://bugs.freedesktop.org/show_bug.cgi?id=57754 Note: This is a candidate for the stable branches. Tested-by: Ian Romanickian.d.roman...@intel.com This commit removed not only the else emit warning block, but the whole NULL check as well. Apparently it's necessary, so put it back. Hi Kenneth, The assertion says the 'irb' is null, but you're checking if the context is null. Off hand, I think a irb==null check is needed in intel_delete_renderbuffer(). Maybe seeing a stack trace would shed more light on where the null irb/ctx is coming from. In any case, if you need to check for ctx==null, please do that in intel_delete_renderbuffer(). The deal is that some (most?) drivers don't need a context handle in order to free a renderbuffer. In the gallium state tracker we use the context to free a piece of context state that's associated with a renderbuffer, but the renderbuffer itself can be freed without a context. Sorry for the headaches this one is causing. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Restore NULL context check in _mesa_reference_renderbuffer_().
On 12/08/2012 05:40 AM, Brian Paul wrote: On 12/08/2012 01:10 AM, Kenneth Graunke wrote: Starting KDE on i965 makes the X server die in a fire with the following assertion: X: intel_fbo.c:94: intel_delete_renderbuffer: Assertion `irb' failed. Obviously, this is rather unpleasant. Bisecting revealed that: 006918c0db77e945ac56b15bc64eba502b86d56c is the first bad commit commit 006918c0db77e945ac56b15bc64eba502b86d56c Author: Brian Paulbri...@vmware.com Date: Sat Dec 1 10:52:42 2012 -0700 mesa: remove warning message in _mesa_reference_renderbuffer_() We were warning when there was no current context and we're about to delete a renderbuffer, but that happens fairly often and isn't really a problem. Fixes http://bugs.freedesktop.org/show_bug.cgi?id=57754 Note: This is a candidate for the stable branches. Tested-by: Ian Romanickian.d.roman...@intel.com This commit removed not only the else emit warning block, but the whole NULL check as well. Apparently it's necessary, so put it back. Hi Kenneth, The assertion says the 'irb' is null, but you're checking if the context is null. Off hand, I think a irb==null check is needed in intel_delete_renderbuffer(). Maybe seeing a stack trace would shed more light on where the null irb/ctx is coming from. In any case, if you need to check for ctx==null, please do that in intel_delete_renderbuffer(). The deal is that some (most?) drivers don't need a context handle in order to free a renderbuffer. In the gallium state tracker we use the context to free a piece of context state that's associated with a renderbuffer, but the renderbuffer itself can be freed without a context. Sorry for the headaches this one is causing. -Brian Sorry for the false alarm...this was my fault. Apparently on my system X is loading an older i965_dri.so, but likely a new libGL. The incompatibility between the one-argument intel_delete_renderbuffer and two-argument gl_renderbuffer::Delete caused something stupid to happen...maybe I got the renderbuffer passed as the context, and NULL for the renderbuffer. I put both halves back in sync and everything's fine now. Again, my apologies for the trouble. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
