On Sat, Dec 1, 2012 at 1:43 PM, Ian Romanick <[email protected]> wrote: > On 12/01/2012 09:56 AM, Brian Paul wrote: >> >> From: Brian Paul <[email protected]> >> >> 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 > > > I'm really confused. A previous patch added the context pointer to > gl_renderbuffer::Delete with the commit message > > We sometimes need a rendering context when deleting renderbuffers. > Pass it explicitly instead of trying to grab a current context > (which might be NULL). The next patch will make use of this. > > But we're allowing NULL to be passed in all the same cases where it could > have been NULL before. Right? What is preventing st_renderbuffer_delete > from dereferencing a NULL pointer (instead of accessing freed memory)? Does > it just leak memory now? > > In any case, this makes the warnings go away on i965. > > Tested-by: Ian Romanick <[email protected]>
Yeah, this is kind of confusing. When we delete user-created renderbuffers we always have a rendering context, so that's simple. When we delete winsys renderbuffers we may or may not have a context, and that varies a bit between DRI drivers, gallium and xlib+swrast. So far the only place where we really would like to always have a context for RB deletion is in gallium where we have a per-context pipe_surface object associated with renderbuffers. I might need to add a null pointer check, as you suggested, in st_renderbuffer_delete() but I don't have easy access to my system to test right now. Maybe tomorrow. -Brian _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
