Hunting the big ctd

[dinger 1]

I'm trying to isolate the conditions that cause a big CTD in both MP and SP modes. We all know this one. Here are the conditions under which I can recreate them with 100% repeatability:

First, a mod note:

I'm dealing with this because it is affecting the mod we're building, CoC_UnifiedArtillery. In the conditions I'm describing, the only mod used by the mission is CoC_Arty. As some of you may have guessed, however, it involves an aggressive use of scripts, functions, and global variables. While they're currently set for minimal FPS impact (long ~ cycles), there is a good deal of stuff in memory.

Now, the repeatability conditions:

A) Large memory mission running. In CoC_Arty terms, this means 3 "Assets" (groups of one or more firing units) on the map. This in itself usually suffices.

B) A certain amount of elapsed time since mission start. (5 minutes? 10 minutes? 15? -- to be determined).

And the symptoms:

1) Corruption of any save.fps or autosave.fps file, and associated problems ("Savegame bug")

2) CTDs:

a) on Retry (from mission start) (it does the "Get Ready" or whatever screen then explodes)

b) on a second preview from the Mission Editor (same as 2a)

c) on a #Reassign or #restart in MP. In MP games, first the server crashes when it hits the Briefing screen, kicking the users off. If the server is rebooted, and the same mission is selected, and the players keep the same OFP session, they crash when they hit the briefing screen.

3) 1.92 actually gave me a flashpoint.rpt file!

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

=======================================================

Date: 09/30/03 Time: 18:39:40

-------------------------------------------------------

Exception code: C0000005 ACCESS_VIOLATION at 005D6BF7

Version 1.92

Fault address: 005D6BF7 01:001D5BF7 C:\Program Files\Codemasters\OperationFlashpoint\FLASHPOINT192BETA.EXE

file: uatut6

world: Noe

Prev. code bytes: 01 00 00 8D 7B 04 8D 49 00 0F B6 4F 01 0F BE 07

Fault code bytes: 8B 55 04 89 4C 24 10 8D 34 40 51 DB 44 24 14 C1

Registers:

EAX:0000000A EBX:178C9C24

ECX:00000080 EDX:00000000

ESI:128EDE80 EDI:178C9C28

CS:EIP:001B:005D6BF7

SS:ESP:0023:0012EC08 EBP:FFFFFFF0

DS:0023 ES:0023 FS:0038 GS:0000

Flags:00010202

=======================================================

So, anyone else have any data points to add? (such as other conditions where this bug pops up)

I'd really like to fix/work around this so I can get this mod out.

[dinger 1]

Okay, I excluded a couple of options.

I tested on desert island and nogova with a lot of artillery:

1 BTLN of M109s (6x4)

1 of M101s (4x6)

1 battery of M270s (3x1)

2 sections of M252s (2x4)

In flashpoint terms, that's that many vehicles and 6 groups of 12, 4 of 6, 3 of 4, and 2 of 4, plus the an obelisk group and vehicle (total 60 vehicles), plus a player group, plus 61 init EH calls starting 60 scripts, all but one of which terminate, but not before starting 30 more background scripts.  The obelisk created a child object (off the fire class), and the various units spawned a bunch of gamelogics (75 by my count), and initialized a ton of unique global variables (something on the order of 600).  In the course of the mission, I triggered a helluva lot of Fired EHs, and a bunch of other transient scripts, and started another 16 processes, so at retry I had something like 47 scripts running.

It retried and saved repeatedly without a problem. .fps File size was around 2 megs.

On nogova once I saw a CTD on retry (after engaging friendly units).  I could not duplicate (but in that one case I wasn't saving to a named user mission), but reloading the mission from the fps saved in the .Noe folder worked (=the save .fps file was not corrupt).  restarting the mission from there (even with remerging the mission) didn't cause any trouble.

So I added in a bunch of East units, and they started shooting at each other.  .fps files jumped to 7k, but again, I couldn't get it to trigger.  Note that none of the units had waypoints (and that's a common feature in all my crashing missions -- they all have at least move and cycle waypoints)

edit: ugh

So I play for about 20 minutes on nogova, at this setting, save, then get killed shortly thereafter. retry works. 5 seconds later, I hit "load" and CTD. So I restart, reload the fps, and it works. Doing the same thing doesn't CTD. The only constant I see here is a big mission, with the enemy, and playing for a certain amount of time before retrying.

[Acecombat 0]

I seem to get a lot CTD's lately dunno why .... but it is usually preceded by looking at a part of the map when you have a lot of open distance infront of you , i think the refresh rate doesnt handles OFP too well or something but i hate it , when i start a mission it only works for 1-2 min and BANG desktop although this occurs infrequently but when it does its annoying

Although in your case its perhaps that view distance needs shortening since it taxes the GF too much and memory , i think a PC with 1-2 GB RAM can handle such stuff without CTDing

My 2 lousy cents hope i didnt bother.

[dinger 1]

no problem there. The only problem witht he viewdistance theory is that I've been able to get repeatable results in MP sessions (at vd 900) with people who have everything from a 3.06 pentium and radeon 9700 to duron 600s and GF2s. And what I mean by repeatable is that the thing resets on all machines.

Oh yeah, and that reminds me, UA clients don't eat that much gas. Some guys were running the minimum: 1 script (plus the fired EHs), and all the global variables and arrays.

[nyles 11]

Are you using the test version offered by BIS 1.93C? It might help in tracking the source of the problem due to an advanced loging feature. Contact BIS and ask about it. It might be worth a try. There have been a lot of C2D fixes since 1.92 (with 1.93C being the latest test version) thanks to people testing it and providing the log files to the guys at Bohemia Interactive.

[lee_h._oswald 0]

I can easy produce a CTD with my OFP.

First, my settings/configs are "modified" for high graphics qualy.

---

Ok, using no addons(only highsky and soundmod, but same result without):

Flying with A10 at 2500 viewdistance over nogova.

Frames per second at 20...40 = All ok, you can fly until fuel is empty.

Frames per second 7...13 = after ~1-2minutes Crash to desktop.

flashpoint.rpt says this:

Quote[/b] ]=====================================================================

== D:\Programme\Codemasters\OperationFlashpoint\FLASHPOINT192BETA.EXE

=====================================================================

Exe version: Wed Sep 03 21:08:22 2003

graphics: Direct3D HW T&L , Device: NVIDIA GeForce4 Ti 4600, Driver:nv4_disp.dll 0.0.0.0

resolution: 1280x1024x32, w-buffer

Addons:

Bizon in bizon\, Su25 in su25\, 6G30 in 6g30\, BIS_WeaponPack in o_wp\

BISCamel in biscamel\, BMP2 in bmp2\, trinity in trinity\, Kozlice in kozl\

Steyr in steyr\, AH64 in apac\, Vulcan in vulcan\, Hunter in hunter\, Kolo in kolo\

Mini in mini\, Trabant in trab\, G36a in g36a\, SoundLDDK in soundlddk\, BRDM in brmd\

Ch47D in ch47\, HMMWV in humr\, LaserGuided in laserguided\, Noe in noe\, OH58 in oh58\

XMS in xms\, BIS_Resistance in o\, Flags1 in flags\, MM1 in mm-1\, Bradley in m2a2\

Mods: RES;@nüschts

=======================================================

Date: 10/01/03 Time: 13:12:28

-------------------------------------------------------

Exception code: C0000005 ACCESS_VIOLATION at 004F2905

Version 1.92

Fault address: 004F2905 01:000F1905 D:\Programme\Codemasters\OperationFlashpoint\FLASHPOINT192BETA.EXE

file:

world: noe

Prev. code bytes: 08 00 00 8D 4C 24 2C 51 55 33 FF 57 89 7C 24 38

Fault code bytes: 8B 10 50 FF 52 2C 8B F0 3B F7 75 08 8B 44 24 28

Registers:

EAX:00000000 EBX:15567250

ECX:0012F83C EDX:7FFE0304

ESI:00000024 EDI:00000000

CS:EIP:001B:004F2905

SS:ESP:0023:0012F804 EBP:00000048

DS:0023 ES:0023 FS:0038 GS:0000

Flags:00010246

=======================================================

What ever that means?!

MfG Lee

[suma 8]

It seems some people still do not know, that ....

the most efficient help for crashing is here and there.

Send your files, and your problem will be very likely pinpointed quickly.

[lee_h._oswald 0]

Better use the time, working on ofp2.

MfG Lee

[dinger 1]

True, and there are many ways to precipitate a CTD in OFP, some of them by scripting and some by improper settings. I was under the impression though that since this phenomenon is 100% repeatable on a variety of platforms (="contained"), occurs in the period between missions (and hence is not directly caused by something I did), but the culprit is not identifiable (="isolated"), I would get some response from others who have seen it.

In any case, I will go ahead and send off the files, and if someone can tell me what we need to do to avoid the problem, it would be greatly appreciated. None of us wants to get yelled at for a CTD bug.

[Acecombat 0]

I have exactly the same problem as LEE

ihate it i just got thrown out 5 times while making a mission jeez this sucks

[toadlife 3]

Quote[/b] ]ihate it i just got thrown out 5 times while making a mission jeez this sucks

<s>If you are making a mission, and you put conditions in your waypoints keep in mind that putting a blank condition (the default is 'this (or true?)') in a waypoint will cause a CTD 100% of the time.</s>

Edit: It appears, that bug doesn't exist anymore.

[Acecombat 0]

No the default 'this' is there btw i didnt even get to that point....

[suma 8]

Quote[/b] ]In any case, I will go ahead and send off the files, and if someone can tell me what we need to do to avoid the problem, it would be greatly appreciated. None of us wants to get yelled at for a CTD bug.

If you want to help us make OFP more stable, you can - all you need to do is to send your context.bin and Flashpoint.rpt files (both) via e-mail to support@bistudio.com immeditatelly after each crash experience.

The sooner you send your files and the more you send of them, the higher the chance we will fix it in the upcoming patch. Even if we cannot fix it, we can suggest you a workaround.

[toadlife 3]

No the default 'this' is there btw i didnt even get to that point....

OK. I spent many hours figuring out that this was causing a map I was making to CTD, so I figured I'd let you know.

[Acecombat 0]

Ok SUMA i am sending the files  and i have got news the CTD is getting even worse i was playing on Kegetys Winter Nogojev (it worked fine previously) and i couldnt even polay for more then 10 secs   ...The screen stutters the FPS drops to 8-9 and then BAM CTD  

Ok thanks Toadlife... i'll wait.

[Unhappy customer 0]

I can guarantee a CTD in under 30 sec in OFP.  Go download the RAD F/A-18 Hornet pack, and fly one of these over Nogova in the mission editor at low altitude and high speed.  It works for me every time   . Oh and by the way I have yet to hear from BIS on this problem after sending them my specs over a week ago...

[bn880 5]

As you are instructed, send the context.bin and flashpoint.rpt right after the crash to support@bistudio.com

sending only system specs is not enough.

Look, the developers are offering assistance, so let's cooperate.

[dinger 1]

well, that's not what I had in mind when I started this thread. My mistake. Sorry guys.

Folks, OFP gives you a lot of control over the graphics settings. If you set viewdistance to something unreasonable, 32-bit depth, superhigh resolution graphics, use a fancy new mod with high-detail textures and integrated scripting, and then try to fly at 600 mph across an objectively dense terrain, well, you're asking for it.

--

one other thing about the flashpoint.rpt file:

I just found out the day before yesterday that -nosplash suppresses the generation of a flashpoint.rpt file. This explains why I only started seeing these files when testing 1.92.

[bn880 5]

I actually use -nosplash and got an RPT with it. So I'm wondering if it's just related to some larger situation, but not directly "connected" to the rpt.

[nyles 11]

Sometimes these files are not properly created after a crash. Thus BIS provided the 1.93x versions with an extended logging feature and already applied several bugfixes to the latest 1.93 test versions (1.93B and C).

Again, I think they will be very happy to include you into the testing process, if you are willing in to send in the logging files when using 1.93 regularly.

[Acecombat 0]

Welli'll gladly test 1.93 for BIS if they want us too

I sent my bin and rpt files too lets hope they come up with something i cant play ofp now its stuttering like hell it didnt behave like this before

[Unhappy customer 0]

Yes I did send BIS my system specs, AND the requested OFP files a week abo. Still no response. Forgive me for sounding impatient, but I have been strugling to make this freakin game run without crashing for almost a year now. After countless hours tweaking Windows, my BIOS, and the game, (and the loss of a hardrive partition *cough*) I am still plagued with this problem. I know it isn't an addon, because this happens even after a clean install after removing all the third party addon and mod folders. I know it isn't the view distance or terrain detail because I have tried turning these all down to minimum settings. I know it isn't Still it will crash when I fly an A-10 over Nogova at low altitude and at high speed, or even during a regular specops mission. And this is with all the detail settings and preference settings on low. Turning down the detail settings only prolong the amount of time you can fly in the mission editor before it crashes. I know it isn't because my CPU sucks because I just built a new P4 2.4Ghz 800Mhz HT with 256megs DDR400 and an Nvidia GeForce4 TI4400. I have been to every troubleshooting werbsite and forum. It seems BIS is too busy inventing new ways of trying to defeat software pirates (FADE) to take care of their customers. I know that I am not the only one with this problem. I have been to countless forums and have seen lots of othe people complaining about this problem. This is driving me insane. I simply can't invest this much time just trying to make this stupid game work. The original OFP was awsome, but then you guys had to go screw it up with the resistance expansion. I think I'm gonna go buy BF1942 now...

[bn880 5]

I understand your frustration, sorry I thought maybe you have not sent them the files so I just re-iterated.

Hopefully they are trying to address the issue. Try 1.93C and see?

[toadlife 3]

@unhappy customer

I've read your posts and feel for you. After looking at all of them, I am beginning to think you *may* have a flaky piece of hardware in your computer. If you have done fresh installs of windows and OFP and have all of the proper drivers installed and OFP still crashes to the deskop, then hardware is the next thing you need to take a hard look at. Even if OFP is the only program that crashed on your computer, it doesn't mean hardware isn't the problem. I had a computer once that ran everything just fine except for Nascar Racing by Papyrus/SIerra. I was never able to get it working depite repeated calls and emails to Sierra's tech support, but when a part of the motherboard went bad and we were forced to replace it, all of a sudden Nascar Racing worked like a champ. All along it had been the crappy generic motherboard that came with the computer.

Unfortunately flaky hardware can be next to impossible to diagnose, especially if you don't have spare parts lying around.

Here are some ways to isolate hardware problems. You mgiht allready know this stuff, or have tried this stuff, but this might help others too:

When doing all of the following, don't turn your OFP settings down - turn them up. You want to TRY and make the game crash.

* Remove everything installed in your motherboard, except of course, your video card. If your sound is integrated into your motherboard, go into your device manager and disable the device. Load up OFP and start playing. If OFP crashes, you have eliminated every device you just removed/disabled.

* If you have two sticks of memory, take one out. If OFP still crashes, try the game with just the other stick installed. If you happen to have another computer with the same type of memory, then try putting those memory sticks in your CPU. ALso, try each each stick in every memory slot. I've seen induvidual memory slots go bad. If OFP still crashes then you either have two bad sticks of memory (is your memory made in China?) or your motherboard is the culprit.

* If you have another computer with a video card that supports OFP, or have another video card lying around, try ofp with a different video card.

[bn880 5]

I can wager to say it may be the system ram... but who knows.