FF Crisis Core - Crash at the beginning with Fast Memory and Multithreaded On

[DonelBueno]

Crisis Core crashes at the beginning with Fast Memory On since v0.9.8-558-g9164e70.

The game crashes at the following scene as soon as the damage number is supposed to appear:

[solarmystic]

@DonelBueno I'm not seeing the issue on Windows x64 using the latest git build with Fast Memory On:-

The damage numbers appear as expected, and the game continues smoothly.

What's your tested platform/specs?

System Specs:-

[DonelBueno]

Try turning on "Linear on FMV" to see if the crash occours on your side.

[solarmystic]

@DonelBueno I've already done that, I have "Linear on FMV" on by default to smoothen out FMVs. No crashes.

Hmm.. any other settings you may have enabled that aren't default, like Multithreaded? I have Multihreaded disabled.

[DonelBueno]

I've tested a lot of settings, including multithreaded, the only one that makes the game crash is Fast Memory.

Curious note: I have Linear on FMVs on and I don't get the black boxes caused by linear filtering you do get in your screenshot. v0.9.8-558-g9164e70 was the first build that solved this issue for me.

That is, the emulator correctly identifies that no FMV is running while in-game, which it didn't before.

[solarmystic]

@DonelBueno Those black boxes are a result of a modification I employed because Linear Filtering would be broken in certain other games (like Tekken 6) otherwise.

I just readded

    if ((g_Config.iTexFiltering == LINEAR || (g_Config.iTexFiltering == LINEARFMV && g_iNumVideos)) && !gstate.isColorTestEnabled()) {
        magFilt |= 1;
        minFilt |= 1;
    }

in TextureCache.cpp at line 637 to "fix" it.

The sideeffects are the black boxes in Crisis Core, but it is a small price to pay (in my opinion) for working Linear Filtering in all other games.

See the issue on Tekken 6 for more details.#4405

Do you have a compiler? It'd be interesting to see the stacktrace of the crash when it happens.

[DonelBueno]

Can you test without your modification?

I don't have a compiler, I used to have Visual Studio, but it wasn't worth to have it installed just for debugging PPSSPP.

[solarmystic]

@DonelBueno I get the same results (it does not crash) without the modification and setting Linear to FMV:-

[unknownbrackets]

Are you using a 32-bit build? If so, please try the latest git build after it pops out of the buildbot. This could be related to #6249. Turns out it was happening on Windows 32-bit as well.

-[Unknown]

[DonelBueno]

No, I'm using a 64-bit build.

I'll test with a 32-bit build and with the lastest build too.

EDIT: Still crashes on 0.9.8-1214 with both 32 and 64-bit builds

[psennermann]

On my system with fastmem enabled this game doesn't seem to crash (ppsspp 9.8-1211 buffered rendering - Windows XP 32-bit - Intel e8400 - Nvidia GTX650Ti)

[unknownbrackets]

Are you using cheats? What region are you using - US, JP, EU?

-[Unknown]

[mckimiaklopa]

Also happens to me on 2 of my phones(Power Vr and Broadcom Videocore IV) and it also happrns on may parts of the game

[unknownbrackets]

@mckimiaklopa You're using the very latest git build, right? Older recent ones did have a problem that caused crashes in some games on Android.

-[Unknown]

[mckimiaklopa]

The crashing it crisis core was always thero on my phones since like forever and thats why i play it with it turned off.Everytime I update ppsspp to the latest build,i test crisis core with fastmem on and it always crashes

[unknownbrackets]

Fastmem is something that should either crash on all platforms, or not crash. It shouldn't be device dependent, except for e.g. armjit bugs and crashing on all Android devices.

-[Unknown]

[DonelBueno]

The crash still occours here (0.9.8.1235). I'm using the US version, ULUS10336, and I'm not using cheats.

I'm sorry I can't help =/

EDIT: This is the pull request that made it start to crash on my side: #5987

[unknownbrackets]

Are you using multithreaded? That change only affects multithreaded.

-[Unknown]

[thedax]

It only crashes with multithreaded turned on (in conjunction with FastMem turned on).

[DonelBueno]

Exactly what thedax said.

[psennermann]

Yes, only with multithreaded+fastmem I can reproduce the crash

[psennermann]

...but that's only on Windows, on my Android tablet even with multithreaded+fastmem enabled the game doesn't seem to crash

[psennermann]

On Android it doesn't crash when damage numbers appear, but it do always crash later during the game after you've spoken with Angeal's mother and exited her house (only if multithreaded+fastmem are both enabled)

[unknownbrackets]

The most interesting thing is if invalid reads/writes are hit with fast memory off.

The game crashes pretty reproducibly for me, it enqueues a list and then updates the stall a billion times. It doesn't look like there's any ge signals, syncs, or anything else nearby.

This "fixes" it:

    void ScheduleEvent(Event ev) {
        {
            lock_guard guard(eventsLock_);
            events_.push_back(ev);
            eventsWait_.notify_one();
        }

        if (!threadEnabled_) {
            RunEventsUntil(0);
        } else if (EventType(ev) != EVENT_SYNC && IsOnSeparateCPUThread()) {
            SyncThread();
        }
    }

By ensuring that the cpu thread waits for all gpu operations (essentially it's just a slower version of multithreaded being off at this point, it's only academically multithreaded.) This confirms it's nothing to do with the mechanics specifically of multithreaded.

The CPU is not especially far ahead of the GE when it crashes either. I don't know if we can make the timing precise enough, and if we do multithreaded will probably be slower than multithreaded off.

-[Unknown]

[psennermann]

You're saying that it should crash even with fastmem off? Strange, I've tested a lot FFCC with multithreaded on and fastmem off and didn't get a single crash...

[unknownbrackets]

No, it still hits the invalid address though. If you turn off "ignore invalid reads/writes" or whatever it's called, it will trigger the debugger. With ignore enabled, it just "keeps trying" when something that would crash fast memory happens.

-[Unknown]

[psennermann]

But why 9.8-553 multithreaded+fastmem doesn't crash while in 9.8-558 it definitely crashes?

And If the problem wasn't fixable, wouldn't it be "safer" to have multithreaded grayed out when fastmem is enabled and viceversa?

[unknownbrackets]

#5987 makes it periodically synchronize with the GE so that it never gets too far behind. This makes it slower and affects timing. Without it, some games will get horribly wrong framerates with multithreaded enabled.

If there's some memory access happening without a way to detect, it's probably heavily affected by timing. So if this is slower or if something else is faster, it will affect it. That's part of the nature of any multithreaded code.

It makes zero sense to me to grey out fast memory when multithreaded is on.

-[Unknown]