View Issue Details

IDProjectCategoryView StatusLast Update
0001044FSSCPFREDpublic2008-11-08 15:19
Reporterkarajorma Assigned Tokarajorma  
PrioritynormalSeveritycrashReproducibilitysometimes
Status resolvedResolutionfixed 
PlatformWindowsOSWindows XP HomeOS VersionSP2
Fixed in Version3.6.10 
Summary0001044: FRED Campaign editor crashes in release but not debug
DescriptionStarting up the campaign editor seems to crash the release build but not the debug.

The crashes aren't perfectly reproducable. Sometime the crash will occur the first time the editor is run (or exited) sometimes I can run it 3 times before it will crash (I have never got it to run more than 3 times before it crashed though).
Steps To ReproduceRun the campaign editor. Try to use a mod which has at least one mission on the campaign list. I think I managed to crash it with non but I can't be certain now.
TagsNo tags attached.

Activities

taylor

2007-10-21 23:32

administrator   ~0008583

* BUMP *

Is this still a problem?

I can't seem to replicate it with current stable-tree builds.

karajorma

2007-10-22 19:01

administrator   ~0008589

Last edited: 2007-10-22 19:04

I haven't tried it recently, I simply used the debug version whenever I needed to build a campaign file but I'll give it a go.

EDIT : Yep. It's an issue. Crashed on me on exit.

karajorma

2007-10-28 22:04

administrator   ~0008611

Tried one of the XT builds just to make sure it wasn't just a compiler error but that crashed too.

taylor

2007-10-28 23:07

administrator   ~0008612

Hmm, I still can't get it to crash for me. If you haven't tried it already, give the 1028 build a go. Attach the error log here, since I've got the map files for those builds, and should be able to figure out where the error is coming from.

karajorma

2008-10-11 13:30

administrator   ~0009934

Using the VC2005 .map file I tracked this down to campaign_filelist_box::initialize() but since 2005 won't let me output line numbers I can't tell where exactly. I'll take another look with a VC6 map file later.

taylor

2008-10-11 14:39

administrator   ~0009935

There is an obvious memory leak in there, but otherwise I don't see much obvious. The only thing that stands out as a possible problem is the strcat(). mission_filenames[] is alloc'd as the exact length of the filename so it's possible that strcat and cause an out-of-bounds issue.

It may be best to change it to use cf_get_list_preallocated() instead. That would take care of the memory error and also make sure that a full filename's worth of space is available. Not sure if that's the issue, but if so then this should fix it.

karajorma

2008-10-14 18:35

administrator   ~0009977

That wouldn't really explain why sometimes the editor runs and sometimes it crashes though would it? If the error is with filenames that are too long then how could I repeatedly start and exit the editor only to crash on the 3rd init in a row?

And if it is an out of bounds then I'd expect debug to crash too as AFAIK it wouldn't have any additional protection against that.

Nonetheless you do raise a good point about the strcat causing problems. I guess I'll have to finally figure out something about how cfile works and fix that anyway.

taylor

2008-10-14 18:58

administrator   ~0009978

Because of the way that the filenames are returned it could randomly cause the crash with strcat (though it should typically be replicated quite often with the same set of data). It has to do with how it strips off the extension when the memory is allocated and then strcat adds an extension back. It could quite easily be linked to the bug that phreak fixed in rev.4872, so you could try again with a current checkout and see if it still happens. If you can't get it to crash then it is quite possible that it was just a low-level windows bug that was biting you.

Also, to help with debugging of release builds I setup the VS2008 project file to generate a full .pdb file. It works sort of like a map file with lines, though it requires a separate program to get at easily. If you have the crash address then you would put the exe and the pdb in the same folder, then open up the exe in a program called CrashFinder. You simply put in the address of the crash and it should give you back the file and line number in question. It's quite a bit less cumbersome that the VS6 map files that have lines listed. If you can get it crash again in a current release build then that should help you track down the cause.

karajorma

2008-10-14 19:04

administrator   ~0009979

I downloaded Crashfinder last week actually but I haven't tried it yet as I could only find the source (and 2 year old source at that!). I use 2005 so I'll check if the options are turned on there (they may well be).

taylor

2008-10-14 19:59

administrator   ~0009981

Last edited: 2008-10-14 20:00

If you can't get a binary of CrashFinder to build let me know and I'll send you mine. The source is just that old though, but it works well so I don't really care. :)

VS2005 does have the same option as VS2008, so just make in the debug options that it creates a program database and that should be all you need (that will create the .pdb).

Issue History

Date Modified Username Field Change
2006-09-13 17:27 karajorma New Issue
2007-10-21 23:32 taylor Note Added: 0008583
2007-10-22 19:01 karajorma Note Added: 0008589
2007-10-22 19:04 karajorma Note Edited: 0008589
2007-10-28 22:04 karajorma Note Added: 0008611
2007-10-28 23:07 taylor Note Added: 0008612
2008-10-10 18:44 karajorma Status new => assigned
2008-10-10 18:44 karajorma Assigned To => karajorma
2008-10-11 13:30 karajorma Note Added: 0009934
2008-10-11 14:39 taylor Note Added: 0009935
2008-10-14 18:35 karajorma Note Added: 0009977
2008-10-14 18:58 taylor Note Added: 0009978
2008-10-14 19:04 karajorma Note Added: 0009979
2008-10-14 19:59 taylor Note Added: 0009981
2008-10-14 20:00 taylor Note Edited: 0009981
2008-11-08 15:19 karajorma Status assigned => resolved
2008-11-08 15:19 karajorma Fixed in Version => 3.6.10
2008-11-08 15:19 karajorma Resolution open => fixed