[Problem] oapiSaveScenario causes access violation

[jedidia]

Quote:

I would wait for the breakpoint before the line that calls "DetachChild" to get hit, set a breakpoint at the beginning of "clbkPostStep", then "continue debugging." Perhaps something in "DetachChild" causes orbiter to call "clbkPostStep"?

That would be a bit absurd, but I did it just to make sure. clbkPostStep is never called during the process.

Quote:

Have you tried looking at the call stack window when the violation occurs? This might show where the function is being called.

It isn't called. That's what I'm trying to say. I'm not looking where the function gets called, I'm asking how it is possible that I end up there without it getting called. I did a search for it, it is called exactly once in the entire solution, and that is in clbkPostStep. The code executed before the crash is nowhere near it.

I can only hypothesize that something overwrites the pointer to DetachChild and this happens to coincide with the address of the function the crash then happens in. But I don't know about how classes and their functions are managed in memory, so I don't know if that's even possible...

---------- Post added at 06:57 PM ---------- Previous post was at 06:36 PM ----------

Replaced the char[200] with a stringstream just to make sure. No change. It's almost as if the very path name would cause a bug in SaveScenario...??

---------- Post added at 07:14 PM ---------- Previous post was at 06:57 PM ----------

Quote:

I don't think this has anything to do with the problem, but you probably want to use strcpy instead of:

sprintf(VesName, GetName());

What you have should still work, though.

It should, shouldn't it? However, it doesn't. This was the freakin' problem!!

using strcpy for the operation, now everything works fine. Now, if someone could explain me why, I might even learn something from this whole affair.

Thanks everyone for the help anyways. I'll just call the guys with the straightjacket back and tell them they needn't come after all...

[Radu094]

Hmm.. funny one! indeed sprintf SHOULD produce an equivalent string as strcpy, provided you do not have conversion specificators(ie. "%s")in the name.Also, IIRC, there was a difference in the way multi-byte-characters are treated, but that shoudln't matter either.

Anyway, I guess it's water under the bridge now that you got it working, but if you're willing to investigate this further, I'd put some padding arround the local variables(eg.):

    char flname[200];
    char padding1[100];
    char desc[200];
    char padding2[100];
    string createPath = "Scenarios/IMS/";
    char padding3[100];
    char VesName[50];
    char padding4[100];

maybe even memset them all to 0, then watch them and see which one changes. Somewhere, something has to leak.

Also, try doing a sprintf(VesName,"%s",GetName()); If sprintf is indeed the culprit, this should also crash it. But if it doesn't crash, then you know is a conversion specificator problem in the GetName();

[Urwumpe]

How did you name the vessel? Something with "%" inside?

[dbeachy1]

To expand on Uwrumpe's point, in general it is not safe to copy a string with sprintf(dest, src) because if 'src' has any formatting characters in it sprintf will expect (and try to parse) arguments that were not sent, which would have unpredictable results since it would be reading uninitialized data. The second argument ('src' above) is the format string, so to safely copy a string using sprintf you would need:

sprintf(VesName, "%s", GetName());

But if all you need to do is copy a string without any characters around it, strcpy is more efficient (and more "correct").

Still, it was a subtle bug -- nobody (including me!) caught it at first.

[jedidia]

Sorry guys, wrong diagnosis... turned out the Bug wasn't as 100% reliable as I thought, and it decided to not show at moments that made me conclude all the things I posted here. They weren't correct. In the end I was able to reproduce it even by just calling oapiSaveState with a normal filename.

I finally solved it (this time for real, it looks like) by waiting a frame after autosave before proceeding. The integration process is somewhat involved, creates and deletes attachment points and docking ports etc. It looks like those functions do not like to be called right after oapiSaveState, for whatever exact reason. I now call autosave when the button is pressed, and then wait until poststep to start the integration process, which seems to solve the problem.

Quote:

How did you name the vessel? Something with "%" inside?

Ha, no, but that's a good thing to keepin mind.