[Droid803]

that is all

(i have no ****ing clue what that means)

[MatthTheGeek]

Thanks for giving so much information. I'm sure it will be very helpful.

[Droid803]

okay, this is as much as I know:

CTD on normal build (FSO has stopped working)
This appears on debug (nothing in fs2_open.log, no debug errors)

Happens about 50% of the time? Thing is it happens sometimes, it doesn't happens sometimes.

I'd give you more information, but FSO doesn't want to give me any more information to give you, you see.

If you want my wild fingerpointing guesses:
- HYPERSPACE
- some collision ****ery?

[CommanderDJ]

You say it happens about 50% of the time. In the times it does happen, is it during a consistent set of circumstances? Are you doing anything in particular when it crashes?

[jg18]

If it's heap corruption, then the crash is presumably just when the corruption is detected. It might have actually occurred well before that.

Not keeping your heap neat and tidy, are you, Droid?

Does it ever occur with RC1? If not, that's potentially a good sign, especially since the changelog for RC2 is relatively short (it even fit in one post).

SCP coders: I bet PVS-Studio is good at detecting red flags for things like this. Just another reason for forward momentum on a second run of that...

[Droid803]

Ther3e's a somewhat consistent chain of circumstances that cause it to happen, but it's never exactly the same time and place...probably because of the aformetioned corruption detection casuing the crash?
I'll give it a try with RC1, but I think this may have been around for a long time...not sure.

[jg18]

A call stack is always helpful if you can get that (instructions).

You might not even need to set up TortoiseSVN, rather just get the Source Code Export from the RC2 release thread and use the VS2010 project there. I think 7-Zip can open .tgz files.

[Droid803]

Just got it to happen with RC1.
I'll try to get a call stack tomorrow, or rather today since it's nearing 1am...(done it before, but will need to get the whole environment setup again due to HDD change)

[FreeSpaceFreak]

There's a somewhat consistent chain of circumstances that cause it to happen

Out of curiosity, what are these mysterious (but nonetheless vitally important for diagnostics ) steps to reproduce?

[Droid803]

Well, it *generally* happens either when: a ship arrives via hyperspace-type warpin, or if there is a collision between two ships at high velocities, hence my two suspicions listed above.

[Droid803]

http://pastebin.com/BAi4ECNK
her
s
ur
calsta
ck

[Echelon9]

Thanks, that's useful to narrow it down to a particular area of the code -- even if the actual heap corruption is happening elsewhere prior to that.

It would be a big help if we could reproduce the crash, could you send a debug log created from a crashing playthrough with a Debug build?

[Droid803]

http://pastebin.com/E0Tb6HGQ
Yes that's the whole thing, it just ends with a bunch of "nothing ok to fire" which IIRC is totally normal during gameplay.

[Echelon9]

Tracking this in Mantis 2897: Heap corruption in dock_evaluate_all_docked_objects() objectdock.cpp

[Echelon9]

This bug might be quite hard to fix without either:

• Mission C4C4 from loliquest -- per the fs2open.log this is the mission which the crash occurred in, or
• A MedaiVPs-based small repro mission that reliably causes the same crash.

We can discuss by PM if easier.

[Droid803]

Oh, it seems to be docking-related.
I could attach the mission if you want, but here's some relevant information:


I have a AK FR Cintamani warping in via hyperspace (star wars) style warping with the following setup:

Tail <- Docks <- Head
the Docks module has three transports docked to it in addition to the head (The tail is the one with the 'arrival cue')
Shortly after arrival, the three transports are jettisoned and given orders to fly waypoints.


The crash itself occurs either when the train warps in (during a cutscene ~30 seconds into the mission), or later during the mission after the train and the transports have been ship-vanished at the end of the cutscene.


EDIT:
if anyone on SCP wants to actually play through the mission with the modpack and all to pinpoint the error, could give SVN access.
if the mission file is all you want I can just post it.

[Echelon9]

Given the mission is likely using custom assets and tables, the full modpack would be easiest to debug with.

Unless you're able to recreate the crash with MediaVPs assets and a simple test mission?

[Goober5000]

EDIT:
if anyone on SCP wants to actually play through the mission with the modpack and all to pinpoint the error, could give SVN access.
if the mission file is all you want I can just post it.

I'd like to play through the mission with the modpack and everything.  Send me a PM.

[Echelon9]

Droid803, I have a code patch that fixes this Mantis 2897 issue. Thanks for providing the mod data, it would have been very hard to track down without it.

Goober5000 is currently assigned for a code review, and then it should be added as one of the few remaining fixes for 3.7.0 Final.

[Goober5000]

I'll be able to look at those in a few hours.