Crash stack trace, demo file, mods, map, dxdiag, and more...

[Short Circuit]

Prometheus:
OS: Windows XP Pro SP2 (32-bit)

Video card: NVIDIA GeForce 7600 GT (two screens, including primary upon which TA runs fullscreen at 1280x1024)
Video card: NVIDIA GeForce 6200 (one screen, sits idle when playing TA)

CPU: AMD Athlon(tm) 64 3400+ (reporting 2.41GHz)
RAM: 1.84GB

Apollo:
OS Windows XP Pro SP2 (32-bit)

Video Card: NVIDIA GeForce 6600 GT
Video Card: NVIDIA GeForce 6600 GT

CPU: AMD Opteron Processor 252 (2 CPUs), ~2.6GHz
RAM: 2736MB (as reported under the XP 64-bit boot)


We're all running TASclient 0.36.

Apollo was acting as server and TA battleroom server. The game was on the local LAN.

At the time of the crash, between twenty-five and fifty tanks controlled by Apollo had just come within range of a row of about fifty medium laser towers backed by seventy nanolathes. (According to Apollo's user. I wasn't viewing the area at the time of the crash.

See included dxdiag files.


History:

We play long multi-game TA Spring sessions at least once a month, often more. (In the last two weeks, we've had four sessions, three of them this week.) Crashes like this are a frequent occurrence. We'd love to see them go away, and I'll be happy to provide more stack traces (and dxdiags of the up-to four machines involved), along with any other information you want. I've included Prometheus's demo file, along with the mod and map we were using at the time.

All the files are at http://shortcircuit.us/spring/crashes/20080329/

It's a crash, so there's definitely something wrong. But I don't exactly know how to report it. (I looked at Mantis, but I wasn't sure if I had enough specific condition information to post there.)

[rattle]

The dxdiag logs are kind of worthless, Spring's infolog.txts are necessary as they hold the stacktrace to see what's wrong.

[Short Circuit]

Doh! I can't believe I forgot to upload the infolog.txt. I seriously meant to.

I checked, and it's since been overwritten with a successful session. Perhaps the provided demo file could be of assistance? (I included the map and mod files so that the demo could be viewed.)

Otherwise, I can post again next time this happens.

[rattle]

Just post them here the next time Spring crashes and someone will look into it. Don't know if the online stacktrace translator is up again.

[Short Circuit]

Looks like my boss is taking a crack at the crashes as well. He found something broken, and fixed it. Next time I post, I'll be running his patched version. (I expect he'll post the patch. I'll have full details next time I post.)

[Flaamwing]

Ok, I've run into 3 seperate crashes. 2 of them I was able to reproduce semi reliably and find the bug.

The first I reproduced when I built lots of nanos, and they were set to roam+patrol. I presume the cause is that on occasion things would go out of range before the nano actually had a chance to help.

Here is the patch that should fix this problem.

--- BuilderCAI.cpp-revBASE.svn000.tmp.cpp Tue Apr 01 21:00:04 2008
+++ C:/Projects/Spring76b1/rts/Sim/Units/CommandAI/BuilderCAI.cpp Tue Apr 01 19:17:51 2008
@@ -349,6 +349,7 @@

if (OutOfImmobileRange(c)) {
FinishCommand();
+ return;
}

map<int, string>::iterator boi = buildOptions.find(c.id);


The problem in this case, was that c happened to be a reference pointer to the first command in the list. However FinishCommand removed the item from the list. Further down in this function, an attempt was made to use this command which was no longer valid. Specifically, it would crash when trying to repair as the command had 0 entries in params, and the assumption was made that there would be 1 or 3 and it was used accordingly. I judged that it was impossible to continue processing a command that was removed however, and put a return there. It solved the problem.

The second problem was more annoying, occasionally aircraft go beyond the limits of the map. Specifically when they are near the edge of the map, and are told to change direction. But fortunately the air combat test was able to show this problem every time by using the SpeedMetalDuo map. I considered changing things such that aircraft modifications to location were always capped to the map coordinates, however that would change the flight path and I'm not sure what else would be affected. (Also, as a side note - air combat test would also try to create units outside the map area with that map.) In the end, I judged it safest to just do a check prior to accessing the height map. The patch is as follows.

--- Unit.cpp-revBASE.svn000.tmp.cpp Tue Apr 01 21:22:48 2008
+++ C:/Projects/Spring76b1/rts/Sim/Units/Unit.cpp Mon Mar 31 23:38:11 2008
@@ -715,7 +715,11 @@
bool inWater = (pos.y <= -3);
bool isFloating = (physicalState == CSolidObject::Floating);
bool onGround = (physicalState == CSolidObject::OnGround);
- bool waterSquare = (readmap->mipHeightmap[1][int((pos.z / (SQUARE_SIZE * 2)) * gs->hmapx + (pos.x / (SQUARE_SIZE * 2)))] < -1);
+ // Cap the units, because occasionally air units can go off the map.
+ // they will come back on, but in the mean time we can't access unavailable memory!
+ int posx = min<float>(max<float>(pos.x, 0), pos.maxxpos);
+ int posz = min<float>(max<float>(pos.z, 0), pos.maxzpos);
+ bool waterSquare = (readmap->mipHeightmap[1][int((posz / (SQUARE_SIZE * 2)) * gs->hmapx + (posx / (SQUARE_SIZE * 2)))] < -1);

// old: "floating or (on ground and height < -3 and mapheight < -1)"
// new: "height < -3 and (floating or on ground) and mapheight < -1"


I created these fixes based on the 0.76b1 tag. However, neither appears to be in the trunk at this time.

One thing I would have a question about, why is it that after building the tag, additional dll's are required that do not exist in the precompiled downloadable version of 0.76b1? Is that tag not actually what was shipped? Also, why doesn't the installer have everything required in the subversion repository, or at least in an additional file that you can download?

One last question, I intend to continue poking at spring and seeing what I can do to fix bugs, or mabey even improve on some stuff if I get familiar enough with it. But what's the most appropriate way to post these patches? Just pick a thread here, or email someone, or is there someplace else that I haven't noticed that they should go?

Regards,
Flaamwing

[LordMatt]

You should definitely post this patch on mantis (i.e. the bug tracker link), and definitely continue to fix bugs and improve things. Spring needs all of the help it can get!

[Flaamwing]

Thanks. Both are posted, with the patch in additional information.

I'm curious about the other things however, any thoughts?

One thing I would have a question about, why is it that after building the tag, additional dll's are required that do not exist in the precompiled downloadable version of 0.76b1? Is that tag not actually what was shipped? Also, why doesn't the installer have everything required in the subversion repository, or at least in an additional file that you can download?

Flaamwing