Internal Error after Winning or Losing an online game.

Bug #896145 reported by cranium
This bug report is a duplicate of:  Bug #896143: Recon Error. Edit Remove
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ares
Fix Released
Medium
DCoder DCoder

Bug Description

As title says, when playing an online game, everyone involved in the game gets this IE right after the game ends. Dosent happen in Skirmish, just online.

http://www.mediafire.com/?8i4lprnrx39q0of

Tags: game
Revision history for this message
DCoder DCoder (dcoder1337) wrote :

The exact same crash as in your last recon report... No idea what's causing it.

Revision history for this message
cranium (cranium) wrote :

oooops, Sorry DCoder, didnt realize it had the same info as last report. So which means the recon errors are totally seperate from that issue then. Arghhh!

Revision history for this message
cranium (cranium) wrote :

Same error happens using trunk, 0.1.1012. Uploaded new crashjdump with rulesmd, and other files.

http://www.mediafire.com/?ingddodcouofjip

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Much as I'd like to help, there's nothing new in this report that wasn't in the last one, it's still burning when trying to read data that's been overwritten earlier. Without blind luck, I don't see how this can be fixed.

Revision history for this message
cranium (cranium) wrote :

The outlying problem has been found. After massive tests between I, Deathnote, and WDF it Seems RA2/YR has an upper limit of 512 for [BuildingTypes]. Assuming BulidingTypes array starts at 0 the limit is 512, if the array starts at 1, then the limit is 513. anything over the limit results in the win/lose crash EIP 0074911D
and assuming this lists works like all other lists that go over the limit, the list starts over from the beginning, so entry 514 would be read as entry 1 hence the "it's still burning when trying to read data that's been overwritten earlier" comment.
So I'm guessing maybe this can be fixed like the 100 unit bug was?

Revision history for this message
Bug Importer (bug-importer) wrote :

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r1016
Commit contains DLL: Yes
Revision comment:
Related to issue #1532 - added developer warnings when counters are resized beyond their limits.
Related to issue 1532 .
SVN: http://svn.renegadeprojects.com/Ares/1016

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

Thanks for the report!

Unfortunately, the data structures are quite different from the ones involved in the 100 unit bug and too complex to be worth modifying, especially this close to a release. Debug.log warnings and guards have been added to the code so that the structures do not exceed their storage, this will probably result in objects beyond index 512 not being counted towards game completion stats (killed/lost/etc) but should prevent the game from crashing.

Marking as fixed, so please test it.

Revision history for this message
cranium (cranium) wrote :

tested, fixed online crash. However I'm concerned that AI is having problems recognizing any buildings above 512. With all countries and sides having the ability to play as AI, theres really no work around for this. And reordering the [BuildingTypes] array will screw with the campaigns.
I'm not sure how Ares future will play out, but instead of just closing this, can we target this issue for maybe 0.3, 0.4 or even later if neccesary?

Revision history for this message
YR M0ddEr (yr-m0dder) wrote :

This is fixed. craniums issue should be reported in a new issue as it seems unrelated to this report.

Revision history for this message
DCoder DCoder (dcoder1337) wrote :

512 building limit affecting AI should be reported as a separate issue, and it will not be considered for 0.2.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.