Bug 12241

First, you'll want to rebuild Mesa from sources in debug mode (make linux-dri-debug).

A stack trace at the time of the failed assertion could be helpful.

Otherwise, I think I can guess what's going on.

Texture objects (see struct gl_texturea_object) are reference counted.  That means anytime we assign a texture object pointer, we need to use the _mesa_reference_texobj() function to make sure the refcounts are handled properly.

Looking at the r300 driver, there's a few places where pointers to texture objects are present.  For example, in r300DestroyTexObj() there's:

	for (i = 0; i < rmesa->radeon.glCtx->Const.MaxTextureUnits; i++) {
		if (rmesa->state.texture.unit[i].texobj == t) {
			rmesa->state.texture.unit[i].texobj = NULL;
		}
	}

That should be changed to:

	for (i = 0; i < rmesa->radeon.glCtx->Const.MaxTextureUnits; i++) {
		if (rmesa->state.texture.unit[i].texobj == t) {
			_mesa_reference_texobj(&rmesa->state.texture.unit[i].texobj, NULL);
		}
	}

Another one is in r300UpdateTexture:

	rmesa->state.texture.unit[unit].texobj = t;

should be:

	_mesa_reference_texobj(&rmesa->state.texture.unit[unit].texobj, t);

Actually, these changes will trigger some warnings because the 'texobj' above is a r300TexObjPtr, not a gl_texture_object *.  So either add some casting or write a wrapper for _mesa_reference_texobj() that takes r300TexObjPtr types instead.

Once the refcounting is done properly, the problem should be fixed.

Created attachment 11401 [details] [review]
Patch adding MESA_REF macro's used for testing

I've build mesa using linux-dri-debug and the attached patch using the refcount updating macros. Now it crashes immediately (before the patch the assert was later). I'll attach a log with a gdb backtrace of the assert.

Created attachment 11402 [details]
gdb log

You'll have to back out your refcounting patch in the r300 driver.  I just realized that the r300TexObj type isn't derived from gl_texture_object.  It hangs off of gl_texture_object::DriverData.

Go back to the orginal code and get a stack trace after the assertion fails.  If you could run with valgrind, that might give some clues.

Created attachment 11576 [details]
backtrace of crash when exiting trackballs

I've reverted the patches, attached is the new backtrace, notice that it now crashes on exit, not directly after being stsrted.

I can no longer reproduce the crash with the latest mesa version from Fedora, and I just found out I already filed the parts going black bug, closing this as a dup of that one.

*** This bug has been marked as a duplicate of bug 11174 ***

Mass version move, cvs -> git