• Welcome to SC4 Devotion Forum Archives.

Debugger 'gdb' usable to avoid NAM game crashes?

Started by GoaSkin, October 05, 2009, 05:07:42 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

GoaSkin

Normally the game crashes if you hover a puzzle piece over a transit-enabled LOT because a game function that automaticly should find out usable rotations (like if you hover an interchange over an existing highway) never finishes in this case.
If you run the game with gdb, the program isn't automaticly terminal if this infinite loop as been started. It is still loaded but discontinued.
I found out that gdb allows you to send assembler commands into open threads. After I sent the command RET (similar to the C++ command break - aborts a running function, ignores the following instructions and continues with the parent function that called it) a few times the bad thread, the game continued normally.

I used the GNU debugger on Mac OS X with the Aspyr port of Sim City. But gdb is availlable for Windows too. May be so that is possible on Windows too. It is a possible solution to avoid these game crashes but it is everything else than user-friendly.


download SC4Config public BETA (RC1)

Pat


Don't forget the SC4D Podcast is back and live on Saturdays @ 12 noon CST!! -- The Podcast soon to Return Here Linkie

j-dub

Its all computer talk. I think Windows behavior is different then Apple's, which Apple is always trying to boast that as their advantage, but I never heard of an Aspyr port on Windows, and since Apples' OS are already prioritized different, this GDB anti-crash for Windows is questionable, only testing will tell.

I have experienced crashes unrelated to transit network issues. But if anything is possible for Windows to not have SC4 crash to desktop, the more crash prevention, the better. It would be awesome to run the game with both sound, music, and day & night cycles on, but its unstable for me, chances are it crashes, so this GDB would not be able to take care of those other issues, would it? When I first got this game on Vista, I had to follow someone else's repacking tutorial to make it not crash so much, it has made a difference, but I can't find anyone who has not crashed with the old puzzle piece over TE, sucks, especially with having to do a station between two puzzle pieces. I am interested in this GDB thing, but hopefully there is not a difference with the original SC4 on Windows compared to the Aspyr port, and running on Apple which GDB was preventing from crashing.

Shadow Assassin

Keep in mind that there is always a reason why the game crashes. The game was never intended to have puzzle pieces in the first place, which is why there is some instability regarding certain situations in-game with puzzle pieces and TE lots.

It's not desirable to maintain an infinite loop, so the game has to crash out after a loop has been executed x times, otherwise it just stays there and keeps attempting to find a solution forever, or until the program is manually terminated. However, I have managed to make the game just freeze without being able to CTD, meaning that it has to be terminated via the Task Manager.

The debugger that Goaskin has discovered may not work well in Windows, since both Windows and Mac have different ways of dealing with such a problem... but give it a try.
New Horizons Productions
Berethor ♦ beskhu3epnm ♦ blade2k5 ♦ dedgren ♦ dmscopio ♦ Ennedi
emilin ♦ Heblem ♦ jplumbley ♦ moganite ♦ M4346 ♦ papab2000
Shadow Assassin ♦ Tarkus ♦ wouanagaine
See my uploads on the LEX!

Andreas

Quote from: Shadow Assassin on October 06, 2009, 12:05:44 AM
Keep in mind that there is always a reason why the game crashes. The game was never intended to have puzzle pieces in the first place, which is why there is some instability regarding certain situations in-game with puzzle pieces and TE lots.

Actually, this is not true - puzzle pieces were there before TE lots were introduced. ;) The in-game highway onramps are puzzle pieces as well, and most likely, the game will crash if you hover a highway TE lot over them.
Andreas

Shadow Assassin

New Horizons Productions
Berethor ♦ beskhu3epnm ♦ blade2k5 ♦ dedgren ♦ dmscopio ♦ Ennedi
emilin ♦ Heblem ♦ jplumbley ♦ moganite ♦ M4346 ♦ papab2000
Shadow Assassin ♦ Tarkus ♦ wouanagaine
See my uploads on the LEX!

dragonshardz

Actually, I've hovered a TE lot over a puzzle piece with no problems. It's puzzle piece over TE lot, however, that always leads to my game crashing.

GoaSkin

@Andreas: Puzzle pieces were introduced before NAM but as highway interchanges. And the binary function used to rotate an interchange automaticly over an existing highway, namely:  cSC4VertexHtConstraintSatisfier::PickASolution(int&, float&, bool&) was only designed for highways. If you hover an highway interchange over a transit-enabled highway LOT (toll booth), there is no game crash.
With the introduction of NAM puzzle piece, a kind of highway interchanges for railroad networks have been created. And for railroad network, the function above fails. It has neither been made to support interchanges for the railroad network nor been tested by Maxis because Maxis did not create any railroad puzzle pieces.

Back to the game crash reason: If you hover a railroad puzzle piece over a transit-enabled rail road LOT, the game tries to find out a suitable rotation but never has success. It rotates by 90°, believes the position is not usable, rotates again, the same and again and again. So  cSC4VertexHtConstraintSatisfier::PickASolution(int&, float&, bool&) is in this case a function that never finishes. The process management of the operating system kernel recognizes that endless periods of the same instructions are running. In this reason, it normally interrupts the program - kills the process. The game crash in this case is a feature of the operating system used to kill programs doing an infinite loop because otherwise the whole system would slow down and freeze.

When running the program through a debugger like gdb, the debugger does not kill the program in this case but suspend. The difference is that the program is stopped but still loaded to let the user decide how to continue. By sending a return instruction to the running thread with the infinite loop function quits and the program continues with the function that has called the malfunction before.
download SC4Config public BETA (RC1)

j-dub

Quote from: Andreas on October 06, 2009, 06:00:18 AM
Actually, this is not true - puzzle pieces were there before TE lots were introduced. ;) The in-game highway onramps are puzzle pieces as well, and most likely, the game will crash if you hover a highway TE lot over them.

Quote from: GoaSkin on October 08, 2009, 04:45:10 PM
@Andreas: Puzzle pieces were introduced before NAM but as highway interchanges.

Either way, that is some dumb programming, the OS is partly responsible too, because I could go on about other programs, not even games, that have crashed, but personally its Maxis'. We must not forget they already had both TE lots AND puzzle pieces before NAM. Hovering an interchange over a tollbooth, BAM! crash. End of game.

GoaSkin

I never realized a game crash by hovering an highway piece over a toll booth but may be I have to try around. I also never had problems when hovering a road piece over a transit-enabled road LOT but even when a rail piece is selected the game does not always crash.
That's mainly because the tiles of a transit-enabled LOT are sometimes locked (if the mouse cursor is over it, the tile beside is hovered).

But I tried a long time to let the game crash using highway pieces and never had success. Only with railroad pieces (and lightrail pieces with additional rail paths).
download SC4Config public BETA (RC1)

debutterfly

This topic I find is very much computer programming which is right up my alley.

Larry (debutterfly)

GoaSkin

I made some tests with the crash bug.

Over transit-enabled highway/ground highway LOTS, you can hover, turn and switch highway puzzle pieces as you want. You can even plug an interchange over an highway tool booth. No problem.

All other networks have that bug. Road/Avenue/Oneway toll booth with a puzzle piece of the same network over it -> crash. If the networks of the puzzle piece and the LOT are different -> no crash.

Because Maxis did only create highway puzzle pieces (interchanges and ramps), there are no crashes when only using the original stuff. Non-Highway puzzle pieces were introduced with the NAM. The game-functions do not well support that.

By turning off the auto-rotation functionality, game crashes may be eliminated permanently. For that, the first instruction of the function listed above needs to be replaced by a jump instraction (JMP) with the address of the end of the function or a direct return (RET). That could be done easily for the cracked EXE because it is a plain binary. The uncracked EXE is encrypted with the key in the boot-sector of the original CD (safedisc copy protection). No chance to create a legal patch. There is also no cracked EXE of the latest version where nightlighting is working.
download SC4Config public BETA (RC1)