2019-12-07 04:35 EST


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001044FSSCPFREDpublic2008-11-08 10:19
Reporterkarajorma 
Assigned Tokarajorma 
PrioritynormalSeveritycrashReproducibilitysometimes
StatusresolvedResolutionfixed 
PlatformWindowsOSWindows XP HomeOS VersionSP2
Product Version 
Target VersionFixed 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.
Attached Files

-Relationships
+Relationships

-Notes

~0008583

taylor (administrator)

* BUMP *

Is this still a problem?

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

~0008589

karajorma (administrator)

Last edited: 2007-10-22 15: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.

~0008611

karajorma (administrator)

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

~0008612

taylor (administrator)

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.

~0009934

karajorma (administrator)

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.

~0009935

taylor (administrator)

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.

~0009977

karajorma (administrator)

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.

~0009978

taylor (administrator)

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.

~0009979

karajorma (administrator)

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).

~0009981

taylor (administrator)

Last edited: 2008-10-14 16: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).

+Notes

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