Bug 12241 - With the game trackballs large parts get rendered black
Summary: With the game trackballs large parts get rendered black
Status: RESOLVED DUPLICATE of bug 11174
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL: http://trackballs.sourceforge.net/
Depends on:
Reported: 2007-08-31 14:20 UTC by Hans de Goede
Modified: 2009-08-24 12:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Patch adding MESA_REF macro's used for testing (1.57 KB, patch)
2007-09-03 12:25 UTC, Hans de Goede
Details | Splinter Review
gdb log (3.44 KB, text/plain)
2007-09-03 12:26 UTC, Hans de Goede
backtrace of crash when exiting trackballs (1.80 KB, text/plain)
2007-09-14 14:15 UTC, Hans de Goede

Note You need to log in before you can comment on or make changes to this bug.
Description Hans de Goede 2007-08-31 14:20:50 UTC

I'm using a radeon 9800 pro, x86_64, Fedora 8 test 1. Fedora 8 test1 comes with
Mesa-7.0.1 (I choose CVS as version as 7.0.1 isn't in bugzilla yet). I'm a
Fedora developer and I'm maintainer of a package of the game trackballs:

I just tested trackballs for the first time in a long time, and it doesn't work properly, large parts get rendered black. This is witrh both 7.0.1 and 6.5.2, in my memory it did used to work in the past, but I'm not sure.

With my 7.0.1 test run I got this I think relevant output:

Mesa 7.0.1 implementation error: invalid reference to a deleted texture object
Please report at bugzilla.freedesktop.org
trackballs: main/texobj.c:278: _mesa_reference_texobj: Assertion `valid_texture_object(oldTex)' failed.

As said I'm a developer / programmer myself, I have almsot no experience with
3d hardware programming, but I'm veru skilled in C and debugging in general. I
would really like to see this fixed, so please let me know what I can do to
Comment 1 Brian Paul 2007-08-31 14:41:45 UTC
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.
Comment 2 Hans de Goede 2007-09-03 12:25:49 UTC
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.
Comment 3 Hans de Goede 2007-09-03 12:26:21 UTC
Created attachment 11402 [details]
gdb log
Comment 4 Brian Paul 2007-09-03 15:05:47 UTC
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.
Comment 5 Hans de Goede 2007-09-14 14:15:02 UTC
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.
Comment 6 Hans de Goede 2007-09-25 00:41:41 UTC
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 ***
Comment 7 Adam Jackson 2009-08-24 12:27:58 UTC
Mass version move, cvs -> git

bug/show.html.tmpl processed on Jan 24, 2017 at 21:24:05.
(provided by the Example extension).