Technical support > Feature Requests

Village mission crash (now with patch)

(1/3) > >>

ubequitz:
Hi all,

Using latest SVN, on my system the mission "village07d" crashes at the start after I first click the next turn button (although it happens only about 1 in 4 times). This could be a bug specific to my system (linux ATi drivers are suspect), or it could be more widespread. If you are interested in testing it is possible to jump directly to this mission and test it. I would greatly appreciate knowing if the problem is not just specific to my box.

To test:
edit base/ufos/campaign.ufo and change the line in the intro section that reads:
    missions  "farm"
to:
    missions  "village"

Then run ufo, start a new campaign, setup a base near the village mission (middle of the USA). Exit the base menu, increase time and wait for the mission. Then send your ship to the mission when it is _daylight_ (night missions don't give me the crash as far as I can tell). Then just hit the next turn button straight away. If it doesn't crash exit and repeat a few more times.

I've managed to get a backtrace of my crash for those interested. See:
http://pastebin.com/777996

ubequitz:
Update: made some small progress.

 I added the debug line:
Com_Printf("CM_TransformedBoxTrace: tile no is %d , cnt is %d, max is %d\n", tile, numTiles, MAX_MAPTILES);

to CM_TransformedBoxTrace [cmodel.c]

I now get something like this right b4 the crash: CM_TransformedBoxTrace: tile no is -1113735969 , cnt is 1, max is 512
The exact tile no does change between runs though.

Something to investigate further....

ubequitz:
I've further narrowed it down a bit:

In  SV_SpanServer  [server/sv_init.c] there is the following code:

--- Code: ---
/* fix this! */
    for (i = 1; i <= CM_NumInlineModels(); i++)
        sv.models[i] = CM_InlineModel(va("*%i", i));

--- End code ---


When I get a crash on the village map I've worked out that this code block assigns sv.model[1] with a model which is later accessed by SV_HullForEntity (via SV_ClipMoveToEntities) [server/sv_world.c]. It looks like this sv.model[1]->tile is unitialized - it is just some random integer.

I don't really understand the SV_SpanServer code entirely. In cmodel.c similar code exists but it filters out models with names beginning with "*" which is the opposite of what the above code does.

ubequitz:
Ok this bug is turning out trickier than I thought. As far as I can tell that suspect code I referenced above is not the problem. Indeed all models start with *, I was misreading some code...

I've checked that the initial assignment of the model in the above code is fine and the model->tile variable is fine initially.

That means sometime between initialization and the end turn that variable (the tile field of sv.models[1]) becomes corrupted.

The saga continues....

ubequitz:
Ok, I've narrowed it right down now.

in CM_LoadMap [qcommon/cmodel.c] there is some code:

--- Code: ---
/* free old stuff */
 for (i = 0; i < numTiles; i++)
        CM_FreeTile(&mapTiles[i]);

--- End code ---


Which frees some tiles. But I've discovered one of these tiles is referenced by sv.models[1]. For example before the frees I can access sv.models[1]->tile but immediately after attempt to access this same variable always crashes. (Note direct access isn't possible in some places so I wrote a function in server/sv_world.c like:

--- Code: ---
void SV_test_tile(void) {
   if (sv.models[1]) {
      Com_Printf("SV_hmm: sv.model->tile %d\n",  sv.models[1]->tile);
   }
}

--- End code ---

to do the testing in various places.

Hopefully somone can look into what the correct behavior here should be.

Navigation

[0] Message Index

[#] Next page