Single Player bugs and crashes - After the 13th July 2013

Status
Not open for further replies.
non-repeatable CTD

mini/save/BBAI in attached. SVN 5770 60X60 VP

1. repeatable CTD after latest SVN 5771 (CTD WHEN loading)

mini/save/BBAI in attached

2. Did a test of the one savedgame BEFORE this, and it works, so something happened inbetween the turns?? (savedgame 383 works, but not above)

3. OK NOW even this one CTD's Here is a different CTD 330am( attached mini/save/BBAI)

I got an immediate CTD when I tried to finish the turn of the attached save. Now I can´t even start C2C anymore by double clicking on this save.

Edit: This is SVN 5771

Well, the 'good' news here is that all but one of these (SO's CTD on load, which just appears to be a broken save file - thought THAT may be a result of saving after the problem that triggers the other crashes, so possible also connected) is the same thing. The evidence strongly points to a concurrency error, and I can see things that might be problematic, but not an entire explanation.

Later today I'll be making some fixes to address the problem I can see, and also adding some extra code in at the point these all fail to provide extra diagnostics next time it happens (which will be in the form of an ugly popup message just before it's about to crash, so be on the lookout for that once I've added it!)
 
Yeah its the new dll that Thunderbrd committed that is "corrupt"

Ok, so far as I understand, you can't commit in such a way that the file is corrupt or you'll simply not commit. I can't re-commit a file that the svn has already received. And it works just fine on this end though I've seen that issue with the ambulances take place before.

Perhaps the merging process isn't quite working somehow? I dunno. All I can say is I can't fix this because I don't have a problem to fix on this end.
 
Ok, so far as I understand, you can't commit in such a way that the file is corrupt or you'll simply not commit. I can't re-commit a file that the svn has already received. And it works just fine on this end though I've seen that issue with the ambulances take place before.

Perhaps the merging process isn't quite working somehow? I dunno. All I can say is I can't fix this because I don't have a problem to fix on this end.

None of the minidumps implicate your changes, so I don't think it's anything you did. I also looked at your changes and couldn't see why they would cause a crash. I DID notice that you'd disabled use of RapidXML though, so that would be causing different processing of the XML, which might be significant - did you check that in accidentally or deliberately?
 
May I ask has the problem where Alt-S signs are lost whenever you save been fixed yet?

I'm looking for a reason to move to a newer version, even SVN if necessary, and that would do me.
 
When running in debug I am getting the attached often.

That's a map script bug most likely - is it specific to one map type? It indicates that the mapscript function 'findStartingPlot' is returning an invalid plot to start a CIV at. If that does happen then the DLL allocates one, so it's not usually harmful.
 
When? When trying to start a new game, or at some other time?

That's a map script bug most likely - is it specific to one map type? It indicates that the mapscript function 'findStartingPlot' is returning an invalid plot to start a CIV at. If that does happen then the DLL allocates one, so it's not usually harmful.

It takes over 30 mins to load a save game so I tried starting a new game. I am using the map script I always use - tectonics.
 
It takes over 30 mins to load a save game so I tried starting a new game. I am using the map script I always use - tectonics.

Chances are it's always returned -1 to that function then (or doesn't define it), and the DLL has always supplied a fallback. It's likely just that you never noticed because only the debug version would tell you. BTW - it's not surprising it takes half an hour if you are using the debug version - it's about 20 times slower than the release version.
 
It takes over 30 mins to load a save game so I tried starting a new game. I am using the map script I always use - tectonics.

Send me a copy of YOUR game, i started playing Tec also, because you said it was a good mapscript, and i agree it is better than most in C2C.
 
Chances are it's always returned -1 to that function then (or doesn't define it), and the DLL has always supplied a fallback. It's likely just that you never noticed because only the debug version would tell you. BTW - it's not surprising it takes half an hour if you are using the debug version - it's about 20 times slower than the release version.

I always use the debug version when I am adding stuff. This is the first time I have ever gotten that message. I have gotten into the habit of reporting all of those messages I get when using debug.

I was playing a game using the normal dll as part of the freeze testing. It was that one with the normal dll that was taking 30mins to load. It is 3gb in size and I have an old machine but it was faster the day before. I update to the latest SVN once or more a day.
 
Previous and current map generator scripts do not seem to place the following resources at all:
- Guinea Pig
- Donkey
- Parrots (I was unable to find parrots in the Map Editor. Could be blind, though; also, I don't know what the icon looks like)
 
Previous and current map generator scripts do not seem to place the following resources at all:
- Guinea Pig
- Donkey
- Parrots (I was unable to find parrots in the Map Editor. Could be blind, though; also, I don't know what the icon looks like)

The icon is the one displayed in the pedia.
 
I really hate tick marks and the extra +/- buttons on the main screen so I turned them off. One turn later they were back even though the options say they are off.

When I saved the game (twice as is necessary to save your option settings), exited and restarted and loaded the options and screens were as I wanted them to be.
 
None of the minidumps implicate your changes, so I don't think it's anything you did. I also looked at your changes and couldn't see why they would cause a crash. I DID notice that you'd disabled use of RapidXML though, so that would be causing different processing of the XML, which might be significant - did you check that in accidentally or deliberately?

Actually that reminds me to be a bit more vigilant about the order in which I do things. I only comment that out for creating the debug dll - its not commented out when generating the final release version. I'll try to make sure I don't commit the source with it commented out any more... easy enough to make sure the debug is compiled first then the final. Sorry about that... hadn't considered the implications that it might mean to the other coders who might overlook that factor.
 
Not the newest SVN (I think it was 5709):

When I load my game it crashes during the loading when the loading bar is about 1/3. I tried it on another SVN build and also a savegame 2 rounds before and 5 rounds before, but none of them load.
 
Well, the 'good' news here is that all but one of these (SO's CTD on load, which just appears to be a broken save file - thought THAT may be a result of saving after the problem that triggers the other crashes, so possible also connected) is the same thing. The evidence strongly points to a concurrency error, and I can see things that might be problematic, but not an entire explanation.

Later today I'll be making some fixes to address the problem I can see, and also adding some extra code in at the point these all fail to provide extra diagnostics next time it happens (which will be in the form of an ugly popup message just before it's about to crash, so be on the lookout for that once I've added it!)

I would strongly advice to not provide SVN 5771 anymore as an official release. I cannot load any save I had done with it anymore, not with an older SVN and not with current 5774. I have lost 15 saves in this way. Saves from a 1 day older SVN (probably 5754) do load without issue.
Unfortunately directly before the release a major bug must have crept in...

I will test further to see how things work out with current SVN.
 
5774 so far runs stable (5 turns).

On another note: With 5774 (5771 was different) I get a changed behaviour when I discover a technology that opens up a new civic. I get the question whether I want to change to the new civic before I get the window that shows me the details of the new technology. Somehow doesn´t feel right...
 
Status
Not open for further replies.
Back
Top Bottom