[http://sourceforge.net/p/ufoai/bugs/2203 Item 2203] imported from sourceforge.net tracker on 2013-01-28 19:26:38

rev 26859
loading 'mine' map crashed :

ufo: src/client/renderer/r_state.c:58: R_BindTexture: Assertion `texnum > 0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb6d736e0 (LWP 11381)]
0xb78b2456 in raise () from /lib/libc.so.6
(gdb) bt full
#0 0xb78b2456 in raise () from /lib/libc.so.6
No symbol table info available.
#1 0xb78b3e08 in abort () from /lib/libc.so.6
No symbol table info available.
#2 0xb78ab3f0 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#3 0x0817f6ef in R_BindTexture (texnum=0) at src/client/renderer/r_state.c:58
__PRETTY_FUNCTION__ = "R_BindTexture"
#4 0x0817f81e in R_BindLightmapTexture (texnum=0) at src/client/renderer/r_state.c:73
No locals.
#5 0x0817f1c5 in R_SetSurfaceState (surf=0x1d3f085c) at src/client/renderer/r_surface.c:60
mod = (const model_t *) 0x17421ca8
image = (image_t *) 0x15aba36c
__PRETTY_FUNCTION__ = "R_SetSurfaceState"
#6 0x0817f375 in R_DrawSurfaces (surfs=0x1ce3d014) at src/client/renderer/r_surface.c:100
i = 183
#7 0x0817f445 in R_DrawOpaqueSurfaces (surfs=0x1ce3d014) at src/client/renderer/r_surface.c:128
No locals.
#8 0x0816d410 in R_RenderFrame () at src/client/renderer/r_main.c:293
tile = 0
__PRETTY_FUNCTION__ = "R_RenderFrame"
#9 0x08093b85 in V_RenderView () at src/client/battlescape/cl_view.c:372
No locals.
#10 0x08074ae1 in SCR_UpdateScreen () at src/client/cl_screen.c:498
No locals.
#11 0x08073580 in CL_Frame (now=1564997, data=0x0) at src/client/cl_main.c:1155
delta = 128
lastFrame = 1564997
#12 0x081378e2 in tick_timer (now=1564997, data=0x19190044) at src/common/common.c:979
timer = (struct timer *) 0x19190044
old_interval = 20
lateness = 50396
#13 0x08137d00 in Qcommon_Frame () at src/common/common.c:1130
time_to_next = 0
event = (struct event *) 0x1cc86f04
#14 0x0818453f in main (argc=1, argv=0xbff59514) at src/ports/linux/linux_main.c:53
No locals.

===== Comments Ported from Sourceforge =====

====== tlh2000 (2009-11-02 06:21:14) ======

interesting - this time it's about the lightmap texnum, not a general texture number like in the reports before.
====== aduke1 (2009-11-27 22:25:27) ======

Just got it 5 mins ago when starting a std campaign in r27238.
====== aduke1 (2009-11-27 23:40:06) ======

It's reproducable here. :)
When staring std campaign, I get the world picture plus a single line of text (truncated left and right).
When the intro switches to the next paragraph, the assert occurs.
r27000 is ok, r27128 isn't. Gonna figure the rev out.

====== aduke1 (2009-11-28 00:18:12) ======

27064 ok, 96 ok, 112 ok, 120 ok, 124 ok, 126 ok, 127 ok, 128 NOT ok.

r27128 is from bayo-fr, titled
"Revision: 27128
Author: bayo-fr
Date: 19:09:30, Freitag, 20. November 2009
Message:
* remove useless check which broke "no limit" width
----
Modified : /ufoai/trunk/src/client/menu/m_render.c

"
I guesss it's your turn, bayo ;)

====== aduke1 (2009-11-29 01:36:59) ======

tlh2000 fixed the assert in campaign intro with r27294 :)

@tlh2000 : Do you think that it was a general fix for that bug ?

@richlv : Does load mine.map *always* crash for you ?

====== tlh2000 (2009-11-29 06:45:37) ======

@aduke1 : no that fix was only for sequence texts
====== bayo-fr (2009-11-29 14:57:58) ======

Maybe it meam there is a memory overflow into R_FontDrawString
====== aduke1 (2009-11-29 17:50:20) ======

r27314 has a trap for invalid texnum.
Let's wait and see what happens...
====== tlh2000 (2010-01-23 06:26:08) ======

also see
https://sourceforge.net/tracker/?func=detail&aid=2936213&group_id=157793&atid=805242
for the same report of a more recent revision

and https://sourceforge.net/tracker/?func=detail&aid=2931359&group_id=157793&atid=805242
====== aduke1 (2010-01-23 10:14:19) ======

The track leads to R_DrawAliasModel().
I added an assert there.
====== tlh2000 (2010-01-23 21:44:33) ======

R_DrawAliasModel is only one potential function here, the problem is a more generic one imo. somehow some textures or images are freed that should not get freed. but why that is happening... i don't know yet. it_static images should not get freed until the game is shut down. but apparently this isn't true for some of them. maybe the it_static flag disappeared somehow. adding further asserts isn't a good idea imo - as we are not getting any more information from it. i've added some ERR_DROP for this purpose already. but they are only telling us which model is affected - which is not particularly helpful (except we find out, it's 100% only for precached models (which image_t pointers in their linked skins should all have it_static afair))
====== aduke1 (2010-01-24 09:51:27) ======

Sorry, didn't know that you already knew so much about this bug.
Anyway, it points to the renderer, which is not by business.
Bailing out.

====== tlh2000 (2010-01-24 09:54:12) ======

no problem - please don't get me wrong - help is more than welcome on this bug.
====== bekoszaf (2010-01-27 14:10:10) ======

I'm not sure but I think this belongs here. Something changed on this. I'm running r28287 and whenever I get the strange textures / a engine crash when loading a mission I get this in the log:

ERROR: Texture is already freed and no longer uploaded, texnum is invalid for model models/soldiers/malemedium/head02b.md2
ERROR: Texture is already freed and no longer uploaded, texnum is invalid for model models/soldiers/malemedium/head01b.md2
ERROR: Texture is already freed and no longer uploaded, texnum is invalid for model models/soldiers/malemedium/head03b.md2
ERROR: Texture is already freed and no longer uploaded, texnum is invalid for model models/soldiers/malemedium/head03b.md2
ERROR: Texture is already freed and no longer uploaded, texnum is invalid for model models/soldiers/malemedium/head01b.md2

It's always the head model. That's usually the one that has strange textures too. BTW: Whenever I get texture corruptions it affects only the head displayed in the upper left, some (not all!) of my actors on the map and usually also the dropship. I noticed no texture problems with anything else e.g. with aliens or other humans. Dunno whether this is helpful.
====== tlh2000 (2010-01-27 15:14:36) ======

that's interesting - the order of added entities to the map is LM_AddToScene, LE_AddToScene, that means that first all misc_models are added to the entity list, followed by the human actors, followed by the ai actors.
====== tlh2000 (2010-01-27 15:19:55) ======

...but still no scenario where you always get these errors?
====== bekoszaf (2010-01-27 17:39:57) ======

Not for me. It works *always* on the first scenario after a restart and it *usually* fails on the second or third. I disabled model caching in the option menu btw. I hoped I could avoid the problem with that but it's no use.
====== tlh2000 (2010-01-27 18:20:59) ======

you are only talking about campaign mode games, no? can you reproduce this with two skrimish matches, too?

did you try to deactivate glsl shaders?

second or third even on the same map? if so, please do a r_listimage for the working map and a r_listimage for the broken map.
====== bekoszaf (2010-01-28 07:09:26) ======

> you are only talking about campaign mode games, no? can you reproduce this
> with two skrimish matches, too?

only campaign yes. dunno what skrimish is. Going to dig into this.

> did you try to deactivate glsl shaders?

In fact I deactivated this some days ago. I hoped it would affect the texturing problem and since my box isn't really state of art I'm sort of happy for every fps I get.

> second or third even on the same map? if so, please do a r_listimage for
> the working map and a r_listimage for the broken map.

Even on the same map. A redo might fix the problem. It might also break the app. Going to dig into those r_list things as well.

BTW: I got some new that confirm the dropship as affected too. After several missions I have some more errors in my log:

ERROR: Texture is already freed and no longer uploaded, texnum is invalid for model models/soldiers/femalemedium/head03b.md2
ERROR: Texture is already freed and no longer uploaded, texnum is invalid for model models/soldiers/malemedium/head03a.md2
ERROR: Texture is already freed and no longer uploaded, texnum is invalid for model models/aircraft/drop_firebird/firebird.md2
ERROR: Texture is already freed and no longer uploaded, texnum is invalid for model models/soldiers/femalemedium/head03a.md2
ERROR: Texture is already freed and no longer uploaded, texnum is invalid for model models/soldiers/malemedium/head03a.md2

====== bekoszaf (2010-02-01 18:57:58) ======

I captured two r_listimages for you

This is where I have the screwed textures:
http://www.maxr.org/~beko/r_listimages_textures_corrupted.txt

I hit "Redo mission" and this time I got this:
http://www.maxr.org/~beko/r_listimages_textures_ok.txt

I hit "Redo mission" several times after that but the textures looked fine for all. Whatever causes the texture corruption is not reproduceable when I redo the mission => something changes something outside of the mission.
====== tlh2000 (2010-02-01 19:17:04) ======


====== tlh2000 (2010-02-01 19:17:27) ======


====== bekoszaf (2010-02-01 19:22:56) ======

I got two more of the same kind. This time I also took a screenshot of the messed up textures:

http://www.maxr.org/~beko/r_listimages_corrupt_farm.jpeg
http://www.maxr.org/~beko/r_listimages_textures_corrupted_farm.txt
http://www.maxr.org/~beko/r_listimages_textures_ok_farm.txt
====== tlh2000 (2010-02-01 19:28:01) ======


====== tlh2000 (2010-02-01 19:29:06) ======


====== tlh2000 (2010-02-01 19:29:15) ======


====== tlh2000 (2010-02-01 19:31:50) ======

in the corrupted lists the firebird texture is not loaded at all. in the list where they are rendered fine, the images are loaded
====== tlh2000 (2010-02-01 20:01:48) ======

notice that the firebird model has texnum 0
====== tlh2000 (2010-02-01 20:11:39) ======

maybe R_DeleteImage is just not working as it should? R_LoadImageData uses this to look up already uploaded textures, possible that this is broken
====== bekoszaf (2010-02-01 20:22:58) ======

I got another one. This time with only the dropship broken:

http://www.maxr.org/~beko/broken_texture_on_dropship_r28370.txt

It may be imagination but I think the texture problem only occures when I get (campaign mode) a mission for another fraction/continent/area then the one before. I tried several times to reproduce this when I got 2 missions almost next to each other on the map and just couldn't get messed textures. When I get another mission far away, like in another area, it happened again very easily.
====== junkie4life (2010-02-01 20:38:46) ======

I attached a log in the forum with some listimages before and after a total hang up.

http://ufoai.ninex.info/forum/index.php?topic=4393.0

I hope it helps
====== bekoszaf (2010-02-01 20:51:50) ======

I got something new. This time the crash was more odd because the engine itself crashed while loading a mission. That happened sometimes. The screen looks as described before. This time I took a screenshot but see for yourself:

http://www.maxr.org/~beko/ufo_engine_crash.jpeg
http://www.maxr.org/~beko/ufo_engine_crash.txt

revision is 28371 including some sanity checks from mattn. Also I got my familiar ERROR: Texture is already freed and no longer uploaded, texnum is invalid for model models/soldiers/malelight/head01b.md2 again in that.

Forget my theory about different areas. I hit a bunch of mission by doing Enter mission => Cancel (Forefit) => Wait for next mission => Enter mission and guess what? It worked every single time. I started to wonder but I noticed that each time I canceled out from a running missions my soldiers were stripped by their armor and weapons. I guess that's a punishment for giving up.

So I went back to the screen were I can equip my soldiers again, gave some random weapons and armor to them, went back to the next mission that I just canceled and BOOM.

So my guess now is that something during the quip procedure messes up the texture memory.

Why's that?

- during rapid testing without droping by on the equip screen it always worked
- after restarting the game after a crash I never checked the equip screen because I started to save the game the moment a mission starts so there was no need to do so
- during a normal game I check the equip mostly before each startup of the dropship to make sure all soldiers have ammo and stuff and that's why I have the "it crashs almost every second time after restarting the game"
- on the equip screen I see the textured dropship and my soldiers and I *never* had texture issues there but that are the only textures that make problems for me.

Can you follow?
====== bekoszaf (2010-02-02 14:03:05) ======

I noticed something further. I played a while to proof my theory and didn't check the equip menu. Instead I used the Buy/Sell menu to make sure I've enough stuff on stock. That went basically fine for a good while until I browsed a little bit through the weapons.

On the next mission my actors had corrupted textures but not for the dropship. My only clue is that something loaded to display the weapons got unloaded again. The dropship was however not affected because this model isn't used in the buy/sell dialog. Neither are the soldiers but their weapons are.
====== tlh2000 (2010-02-02 19:02:02) ======

and this is never happening in the menus for you? only after menu, then map?
====== bekoszaf (2010-02-02 19:53:10) ======

never happening in the menus, no.
====== tlh2000 (2010-02-03 07:31:02) ======

should be fixed in r28384 - freeing the unused skins for models isn't that easy as we currently don't know if not any other model references it, too - that's why R_FreeWorldImages() should not touch it_skin images. It just doesn't know anything about them.
====== bekoszaf (2010-02-03 10:57:47) ======

seems to be fixed but might have caused a new bug. I opened another bug for this with the id #2945158

thanks for the fix!
====== sf-robot (2010-02-18 02:20:12) ======

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).