[Bug 26999] _mesa_reference_renderbuffer: Assertion `oldRb->Magic == 0xaabbccdd' failed

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Aug 17 04:13:57 PDT 2010


https://bugs.freedesktop.org/show_bug.cgi?id=26999

--- Comment #6 from Julien Viard de Galbert <julien at vdg.blogsite.org> 2010-08-17 04:13:57 PDT ---
Well I don't think 'make clean' will rewrite the code, also I did build it by
rebuilding the debian package, and generally this starts by a 'make clean'.

Note that I did rebuild the debian package, not the latest of your code, but
according to git [1] today's struct via_context has not changed much.

[1]
http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/unichrome/via_context.h#n154 

The problem come from the 'struct via_renderbuffer' inside this structure (line
160-164) also line 159 explicitly says it should not be here, so the writer
somehow new this was not that clean.

What my gdb session showed is that the 'struct via_context' get freed while
there are still some reference to the 'struct via_renderbuffer'. So when the
references gets cleared, the assert occurs because the referenced 'struct
via_renderbuffer' has already been freed. (for more details, go and actually
read my post on debian bts).

Maybe the caller should not make the 'struct via_context' be freed in the first
place, however 'struct via_renderbuffer' use a smart reference counting
(inherited from the 'struct gl_renderbuffer') so if it was referenced properly
this would not append.

I propose to replace the 'struct via_renderbuffer' inside 'struct via_context'
by pointers and use the proper reference counting. If this is the right
direction, I'll try to provide a patch. However the comment on line 159 sound
more like there should not be 'via_renderbuffer' here at all... So if someone
can point me to the relevant documentation (to get more insight on how it
should be done) I'll work on it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the dri-devel mailing list