-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
God Of War Ghost Of Sparta: crash jumping down in nexus of atlantis (has workaround) #14958
Comments
Using 30fps cheat code it doesn't crash o_O |
Change PPSSPP CPU Clock To 222MHz, Idk Why But It's Could Fixed Bugs Or Crashing For God Of War : Ghost Or Sparta. |
Did you try? It is work for you in that area? Im using IR Interpreter cpu btw. |
Yes. I Got That Bug Too At PC And Android... |
Anyways, That Method Can Used To Fixed Unlimited Enemy At The Vortex Area |
Unlimited enemy is a different issue. |
Hm, very much looks like a dupe of #6982 ? Which still is an issue indeed. |
What's the minimum disable flags required to avoid the issue? Does it require all three of those? LSU_UNALIGNED is flipped (oops, will fix), but shouldn't do anything if LSU is disabled. -[Unknown] |
I disable those 3 option to prevent from crashing when I load savestate but now LSU is enough to prevent from crash using the latest build 🤔 |
In that case, RemoveLoadStoreLeftRight is my top theory I suppose. I don't think it's LSU directly? L/R stuff is complicated... -[Unknown] |
I also notice a CPU glitch after Kratos jump down. Screenrecorder-2022-07-12-14-17-09-323.mp4 |
i'm using this save state without disabling any JIT functionality, and the crash occurred here:
May be alignment issue? With LSU disabled, ppsspp didn't crashed, only the game crashed Dynarec(JIT) without disabling any JIT functionality also crashing the game: Edit: Apparently i need to enable "Ignore bad memory access" combined with Disabled LSU to prevent the game from crashing |
It could be already corrupt. You're also getting the purple screen which means that something dangerous was done with this save state at some point (i.e. cheats, etc.) It might be best to get a save state near this area using jit and see if it reproduces on IR interpreter. And see if IR crashes from a regular in-game save. -[Unknown] |
@Gamemulatorer could you provide a cleaner save state? may be loading it from save data first and not using any cheat when creating the save state |
I will try later :) |
Sadly, I'm still getting stuck at this point in the game. I tried all the above and still no dice :( |
Was anyone able to upload a clean save state (it would show blue, not purple, on crash)? -[Unknown] |
the solution is : Go into "Settings", then "System" and uncheck "Fast Memory (unstable)." You might want to create a Game Setting for this game with that option turned off... |
check my comment |
check my comment! |
please upload your clean save state here so the devs can test it, and they can fix it if it really related to fast memory, because fast memory shouldn't cause a crash. |
I don't think I've saved it in that spot tbh. I'm way ahead now. But when I unchecked fast memory it genuinely worked and I've seen that solution on Reddit so I thought id share it since it worked for me as well as others :). If you want any save state after this crash I'll sent it for sure |
The best way to fix this issue so that no one has to fiddle with settings would be if we can get a save or save state that is, ideally, just before you enter the area (but close) where this happens. Fixing this bug will most likely mean reproducing it tens of times, although if it's too close to the issue the bug may already be "set in stone." Not asking anyone to go back or anything, but just describing what a developer (such as myself) will need to fix the bug. I'm not actually interested in playing this game, so not asking for a workaround. It's possible the same underlying bug might break the game later (and maybe turning off this setting won't work as a workaround for that case), or might break other games. That's my main interest in this bug. -[Unknown] |
That doesn't help using IR interpreter on my device 🤷 |
I uploaded it, let me know if this helps? |
Uploaded :) |
if anyone wants a save state for right after this bug so they can play, let me know ill upload it :) |
Watch from 12:11 to understand how it's done. (https://youtu.be/iRp8f0AU2Xg) |
Knowing that it crashes in the IR interpreter runloop isn't useful. Think of it this way: imagine I wrote this code: enum StepType {
READ,
WRITE,
};
struct Step {
StepType type;
int offset;
}
uint32_t data[32];
uint32_t RunSteps(std::vector<Step> &steps) {
uint32_t value;
for (auto &step : steps) {
if (step.type == READ)
value = data[step.offset];
else
data[step.offset] = value;
}
return value;
} That's a tiny state machine, with 128 bytes of RAM. It's like a much less complex example of the IR runloop. Now let's say I call this with: steps.push_back({ READ, 0 });
steps.push_back({ WRITE, 1 });
steps.push_back({ WRITE, 2 }); Everything would be okay, right? It could run that and return whatever was in position 0 in RAM, having updated the other two words in RAM. But what if I did this? steps.push_back({ READ, 9999 });
steps.push_back({ WRITE, 1 });
steps.push_back({ WRITE, 2 }); Oh no. I've accessed outside valid RAM - my program crashes. Surely, we could all agree: I could complicate my little state machine by checking if the offset is >= 32. Since I only have 128 bytes of RAM, that's not allowed. Yay, it doesn't crash... but it also doesn't work. Darn. And it just behaves wrong (not loading the right thing at that 9999 line), but I can't tell why because it's silent about the error. That's a problem. So now, let's say I make the state machine a bit more complicated. Instead of only checking for offset >= 32, I show a blue screen and an error message when offset is >= 32. There we go. Now I know that someone called That's what's happening here. That What's interesting is: why did the MIPS code send an address that is wrong? The answer to this question won't be under -[Unknown] |
For me this appears unrelated to IR - even disabling everything in IR, it still happens (at least from the save, even without using a save state.) It seemed to happen less often (?) in interpreter but happened there too. If this issue is just "using the IR interpreter doesn't let me ignore bad memory addresses", I think there's another issue for it. But anyway, the real bug is the crash, which seems to happen for interpreter, IR interpreter, and jit. The crash occurs at 08A67CA8 for me, because the load at 08A67C9C read nullptr, reading from e.g. 0918832C or 097B16EC (it varies.) It seems like this nullptr is written at 08B01734, overwriting 0x09188340 (or etc.) Even if I put that value back, it just crashes later. When it didn't crash (it doesn't always), 08B016F8 ran (with the address of the nullptr read) but there was a correct value loaded in its place. It seems like the timing of it vs 08A67C64 running is what was different? That it's affected by CPU clock makes it seem more likely it's timing. At certain Mhz values (for example 200 Mhz) it seems nearly impossible to reproduce the crash. 08A6A080 instigates the crash when: Comparing the working mhz with broken mhz... I see some IO stuff happening on broken before the call to 08a67c64 with the nullptr. It starts this IO stuff after the nullptr is written, which is the same as working - except that working doesn't call 08A67C64 again after starting the IO. But also, 08A67C64 is called 6 times in working, and 8 times + 1 crash in broken. Some breakpoints of interest0x08A65930 0x08A65854 0x08A67C64 0x08B01734 097b16ec/4 change As an experiment, if I multiply the return of Changing sceIoOpen timing doesn't seem to help. Increasing VFPU op cycles significantly doesn't seem to help. Seems like improving GE timing in some way is the best bet here. Useful save state (immediately before the crash, crashes at 333 Mhz, doesn't crash at 200 Mhz): -[Unknown] |
Another crashlog using IRinterpreter
|
Hello. Can you please? :) |
|
I can confirm this.
Here is the save state file: PPSSPP_STATE.zip |
Updates for https://report.ppsspp.org/games?name=ghost+of+sparta
|
Game or games this happens in
UCUS98737
What area of the game / PPSSPP
Crashing after pressing the L button to jump down
Screenrecorder-2021-10-01-23-14-26-443.mp4
Fast Memory OFF
Ignore Bad Memory Access try ON/OFF
No cheats default graphics settings.
related to #10897 but that issue is about hw tessellation 🤔
What should happen
No crashing just (like using JIT or Interpreter with ignore bad memory access)
Logs
logcat_ppsspp.txt
Platform
Android
Mobile phone model or graphics card
Redmi Note 9 Android 11 Helio G85 Mali-G52 GPU
PPSSPP version affected
v1.11.3-1630
Last working version
No response
Graphics backend (3D API)
OpenGL / GLES
Checklist
The text was updated successfully, but these errors were encountered: