Bug 21756

> I can only restart X to quit games.

Does killing the game processes also work, possibly with kill -9?

Does running the games in valgrind give any hints? Maybe the r200 driver needs texture object reference counting fixes like the r300 got recently in Git commits c28707b50701b1cf8727be29d61e2d939c6ee58f and 09c04db3c900e4ed833d060853b48c7ca23697e1 .

Created attachment 25965 [details]
AssaultCube-exit.log

Created attachment 25966 [details]
AssaultCube-settings.log

(In reply to comment #1)
> > I can only restart X to quit games.
> 
> Does killing the game processes also work, possibly with kill -9?
> 
> Does running the games in valgrind give any hints? Maybe the r200 driver needs
> texture object reference counting fixes like the r300 got recently in Git
> commits c28707b50701b1cf8727be29d61e2d939c6ee58f and
> 09c04db3c900e4ed833d060853b48c7ca23697e1 .
> 

 Yes, killing process works also with kill -9 or killall somewhere also works with CTRL+C (World of Goo). In World of Goo there is no any error message when i call it from console, i can kill it with CTRL+C there, but in RTCW i must switch to another vt console and then i can kill it with 'killall wolf.x86', also RTCW show some error and then freeze when i try to exit:

 ----- CL_Shutdown -----
RE_Shutdown( 1 )
Mesa 7.4.2 implementation error: invalid reference to a deleted texture object
Please report at bugzilla.freedesktop.org
wolfsp.x86: main/texobj.c:305: _mesa_reference_texobj: Assertion `valid_texture_object(oldTex)' failed.
Received signal 6, exiting...

 Some games don't freeze on exit like 'Secret Maryo Chronicles', but emit same error:

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


  In case of Assault Cube if i tried to exit i don't get Mesa implementation error but got freeze and first show some glibc error, but when i try to apply some video settings in game i got same impementation error like in RTCW, logs attached. 

  If that helps, i remember first time when r200 start to have problems with deleted texture objects i think, noticed in ppracer (bug #21019)... I'm not sure, but that seems to be in some conjuction and may be root cause of this problem.

Created attachment 25989 [details] [review]
A patch that corrects this bug.

Commit #63cde0ea0e2bc85005136c353c363777488804d2 deallocates a reference correctly, however the reference to the texture in _Current is never made in
texture_override.
So rather than assignment in texture_override, a reference is made.

Hopefully this will solve the problem - it works here.

Ah right, this is essentially what 7e0f47c1348273ed3bb39d00aa4a9498a28b8d6a does in master... Unfortunately that doesn't cherry-pick to the 7.4 branch cleanly, so I'll leave it to Brian how to handle this.

(In reply to comment #5)
> Created an attachment (id=25989) [details]
> A patch that corrects this bug.
> 
> Commit #63cde0ea0e2bc85005136c353c363777488804d2 deallocates a reference
> correctly, however the reference to the texture in _Current is never made in
> texture_override.
> So rather than assignment in texture_override, a reference is made.
> 
> Hopefully this will solve the problem - it works here.
> 

 Thanks, works for me also.

OK, I've committed patch/attachment 25989 [details] [review] to Mesa, commit 46a2aad2cfec0ae54bc1a3ba5aacf6f59065d64b

Closing this bug.

Looks like a 7.4.3 release will be in order...

Note that the master commit also removes the texUnit->_Current = NULL assignment from update_texture_state(). Without that change, aren't we leaking texture objects again?

(In reply to comment #9)
> Note that the master commit also removes the texUnit->_Current = NULL
> assignment from update_texture_state(). Without that change, aren't we leaking
> texture objects again?
> 

Yes, you're right - I missed that by accident.

Created attachment 26028 [details] [review]
Patch with removed texUnit->_Current = NULL;

Fixes the potential memory leak as described in Comment #9.

OK, I've committed the follow-on patch.
commit 35f5222ae0a16e0ac275110b6cbbbd13f74fd101

*** Bug 21881 has been marked as a duplicate of this bug. ***