2021-09-23 03:43 EDT


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002656FSSCPgameplaypublic2021-03-05 17:09
ReporterGoober5000 
Assigned ToGoober5000 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0002656: skipmemymissionyo fries the campaign file
DescriptionAfter using the skipmemymissionyo cheat, any subsequent attempt to load the campaign file for that pilot will result in a "Malloc Failed!" error. This is caused by an attempt to allocate a ridiculously large amount of memory, which is in turn caused by reading a ridiculously large number from garbage data.
TagsNo tags attached.
Attached Files

-Relationships
related to 0002739closedGoober5000 Pilots corrupted on Vasudan main hall crash 
+Relationships

-Notes

~0013599

Mastadon (reporter)

I can confirm the existence of this bug as of FSO 3_6_14 RC5.

~0013600

Goober5000 (administrator)

It is likely that this bug has been around for a while, as this cheat isn't used very often. It's not even that well known.

I am curious as to whether this bug appears in Antipodes. If the new pilot/campaign code fixes this, then we can probably defer this bug until the Antipodes features are merged into trunk post-3.6.14.

~0013605

CommanderDJ (developer)

Just tested this on Antipodes. I triggered the cheat, loaded a mission, jumped out, then went into both the campaign room and mission simulator in the tech room. Everything functioned as normal. Is this enough, or do you need more testing?

~0013608

Goober5000 (administrator)

The mission simulator has nothing to do with it. You need to access the next mission in the campaign via the Ready Room.

And you should be testing it using a debug build, because it's possible release builds will silently file away the allocation failure for a later crash.

~0013609

CommanderDJ (developer)

Oh, right. Derp.

Yes, I've been using debug builds.

Okay, so I loaded a mission using the cheat, jumped out, then clicked the ready room and played a mission through there. Everything functioned as I would expect.

~0013610

Goober5000 (administrator)

Okay, cool. Can you do the exact same thing with a trunk or RC build, just so that you know what to expect when/if the bug *does* appear?

And incidentally, this is encouraging news, but also thoughtful news. On the one hand, the game doesn't crash; but on the other hand, we don't actually know what is different to prevent the crash. :-/

~0013611

CommanderDJ (developer)

Okay, this is weird. I don't get the bug on latest trunk. Just to be safe I tested AP again. With both trunk and AP I followed these steps:

1. Create a new pilot
2. Click Ready Room. Skip first training, so I have some campaign progress. (Not doing this step didn't cause the bug either.)
3. Go back to main hall. Type in cheat. Enter sm2-01 in dialog box. Commit to mission once briefing pops up.
4. Alt-J. Go back to main hall on debriefing (which was the AWOL debriefing).
5. Click ready room.

Everything functioned fine. Did I do something wrong?

Sidenote: the cheat claims legitimate campaign progress will be destroyed, and with trunk I was indeed reset to training 1, but with AP I kept my progress and when I clicked ready room I was taken to training 2.

~0013857

niffiwan (developer)

I've had this occur twice with different pilots on trunk r9010 (release).

Error 1) ERROR: "Out of memory." at windows_stub/stubs.cpp:570
Error 2) ASSERTION FAILED: "(len < n)" at cfile/cfile.cpp:1269 len: 65792, n: 32

In both cases I skipped to sm3-09 in the main freespace campaign. Both pilots were created just before using skipmemymissionyo. The only thing changed with both pilots was I selected the "don't show me hints again" button.

~0014154

Goober5000 (administrator)

Reminding myself to check this after the 3.7 merge.

~0016787

Goober5000 (administrator)

Seems that the new pilot code removes the crash. I tried a few missions in the main FS2 campaign and things worked fine.

~0017105

Goober5000 (administrator)

Turns out the bug wasn't squashed in the new pilot code. It was later squashed here:
https://github.com/scp-fs2open/fs2open.github.com/pull/2558
+Notes

-Issue History
Date Modified Username Field Change
2012-05-20 17:05 Goober5000 New Issue
2012-05-21 17:38 Mastadon Note Added: 0013599
2012-05-21 22:12 Goober5000 Note Added: 0013600
2012-05-22 07:21 CommanderDJ Note Added: 0013605
2012-05-22 21:24 Goober5000 Note Added: 0013608
2012-05-22 21:34 CommanderDJ Note Added: 0013609
2012-05-22 23:03 Goober5000 Note Added: 0013610
2012-05-22 23:17 CommanderDJ Note Added: 0013611
2012-07-14 06:30 niffiwan Note Added: 0013857
2012-11-22 22:36 Goober5000 Note Added: 0014154
2012-11-22 22:36 Goober5000 Assigned To => Goober5000
2012-11-22 22:36 Goober5000 Status new => assigned
2012-11-22 22:36 Goober5000 Resolution open => suspended
2012-11-30 07:28 The_E Relationship added related to 0002739
2015-09-22 23:08 Goober5000 Note Added: 0016787
2015-09-22 23:08 Goober5000 Status assigned => closed
2015-09-22 23:08 Goober5000 Resolution suspended => no change required
2021-03-05 17:09 Goober5000 Status closed => resolved
2021-03-05 17:09 Goober5000 Resolution no change required => fixed
2021-03-05 17:09 Goober5000 Note Added: 0017105
+Issue History