God Eater 2 cannot do continuous mission

[sum2012]

v0.9.6-562-gd69f02d log
(Turn off fast memory)
https://gist.github.com/sum2012/dcc910b88b34da7bf899

maybe loading\unloading modules problem
edit:I start from new game

[thedax]

Sort of a duplicate of #4537, but that issue was hijacked so continue discussion here, I guess? :)

[sum2012]

Sorry,I cannot search the old issue

[unknownbrackets]

What does the code near 08e70764 look like?

-[Unknown]

[sum2012]

Seem all nop

[unknownbrackets]

If you set a breakpoint there and run it, what does it look like? I guess it unloaded a module... maybe it's unloading it too early.

-[Unknown]

[LunaMoo]

Looks different for me:

(looks same when breakpoint is set at 0x08e70764 before the crash)
That's taken during a crash. When it crashes the debugger freezes(it feels like it refreshes continuosly or something) and have to pause the emulation to be able to click anything inside it.

[unknownbrackets]

Okay, so s1 is differently bad in that case, and it's a function pointer.

Yeah, the debugger doesn't handle jumping to invalid addresses well...

-[Unknown]

[LunaMoo]

After restarting and reloading to make the mission work(same one), some other registers also look differently:

not sure if it matters through, it's almost black magic for me;o

[unknownbrackets]

Well, that value of s1 definitely seems like the more correct one. I would guess this is a problem with resolving exports but I'm not really sure where the problem is.

Does it still happen if you disable jit (in developer options, kinda tucked away on purpose)?

-[Unknown]

[LunaMoo]

Jit off, same crash althrough doesn't freeze the debugger.

[sum2012]

Turn of fast memary and JIT,log seem the same
https://gist.github.com/sum2012/0d7cf3159f0c10850d2c

[sum2012]

@unknownbrackets It is my screen

If you set a breakpoint there and run it, what does it look like? I guess it unloaded a module... maybe it's unloading it too early.

[ghost]

God Eater 2 Prelude Edition DEMO 2
http://exoshare.com/download.php?uid=YCJ01ACG
http://exoshare.com/download.php?uid=1P83QPSL

[Raimoo]

@jack00 what's the use of these link? Spread piracy?

[hrydgard]

Links to demos are fine IMHO, as long as it really is demos that Sony or the game company lets you freely download.

[Raimoo]

Let's not forget that GE2 crash after subsequent mission may cause by block allocation failure as stated in issue #4537. I hope it got fixed soon :(

Edit: issue #4545 has similar problem with this issue eventhough it is more to DLC-related bug

[unknownbrackets]

I wonder if the issue here is our blatant disregard for any of the options in SceKernelLMOption...

Is there an easy (and quick) way to reproduce this that works in the demo? Ideally one that involves not finishing a whole mission, maybe just ending early or holding repeat and X a lot. So I can test things quickly...

-[Unknown]

[thedax]

Doesn't seem like abandoning missions and retaking them in the NPJH90338 (the first demo that was released) has any effect, e.g. the demo doesn't hang when taking another mission after abandoning, so I think that idea's out.

[CPkmn]

@unknownbrackets some possibilities I've thought of :

• maybe PPSSPP's current startmodule/unloadmodule delays are wrong (it's possible that GE2 is unloading too early, similarly I think you mentioned that possibility before)
• in sceKernelLoadModule there's this comment above retrieving a SceKernelLMOption for the function :

// TODO: Use position to decide whether to load high or low
might also cause problems since that's definitely disregarding a portion of module loading.

[unknownbrackets]

I swear I mentioned that somewhere recently. We ignore the entire options struct, that definitely could be related if changing the thread allocation position helps.

-[Unknown]

[thedax]

You did just a few posts above: #5192 (comment). :P

[CPkmn]

the problem is indeed related to not respecting fromTop in ElfReader on the following line

vaddr = userMemory.Alloc(totalSize, false, "ELF");

changing it to true fixes the God Machine (and I suspect finding fromTop correctly there would also fix consecutive missions).

[unknownbrackets]

You did just a few posts above: #5192 (comment). :P

Yay, not senile quite yet, just inattentive and forgetful. I'll take that as a win.

Okay, well, that sounds pretty good. I think we just need to pass either the options pointer or parts of it into the elf reader, and respect them. I also wonder what the flags are...

Thanks for figuring that out.

-[Unknown]

[CPkmn]

@unknownbrackets fwiw I tested the game a bit more and it doesn't use SceKernelLMOption (the option address for each module load is 0)...maybe there's something useful in the elf header? the change I did above does show some fixes, although it breaks some things (most notably, mission description text looks wrong and the archive crashes). it's probably not a good idea to force allocating one way there...

[unknownbrackets]

http://report.ppsspp.org/logs/kind/455 <-- flags generally looks like a pointer, but not always. Hmm.

Either way, indeed seems like this game doesn't use that. Hmm.

-[Unknown]

[CPkmn]

I was talking about the pointer (address) to lmoptions, which is null for this game, and flags are also null. much of the module is discovered after reader.LoadInto(loadAddress) which is why I was thinking maybe something in the elf header could tell, since there isn't much information before loadinto().

[hrydgard]

@unknownbrackets , might be related to firmware version. Maybe they changed it from a regular flags field to a pointer at some point.

[unknownbrackets]

Could be. Or maybe it's just garbage so games don't care what they put in there.

-[Unknown]

[hrydgard]

Well, yeah, that might actually be more likely.

[hrydgard]

That's a typical "FastMem" crash (the and edx,0x3ffffffff before in 32-bit builds are an easy indication), try turning off fast memory , you'll see that you'll get some invalid memory accesses in the log I guess...

[sum2012]

v0.9.8-310-gb4244fb still crash
https://gist.github.com/sum2012/d0ae286b62260e71cb1c

[vsub]

Is this known problem...every time I create a save state,ppsspp will crash.
The state is created but ppsspp crash after that.

I'm using the demo of the game and the problem exist on 0.9.6-537 and 0.9.8-306.
Sometimes it doesn't crash immediately after you save but if you don't restart ppsspp and load the save state,it will crash shortly after you create the state

It's spamming this in the console when I tried 0.9.8-306
W[MM]: MemmapFunctions.cpp:94 ReadFromHardware: Invalid address ff000023

[LunaMoo]

Not sure if a method to quickly reproduce this issue in demo is still needed, but I made a cheat which can make it very quick:
_C1 Mission Complete Instantly
_L 0xE0012402 0x00646296
_L 0x20646290 0x10000004

As soon as the mission starts with this code activated, it'll instantly jump to mission complete, the first line of the cheat is a check which ensures it'll activate only during the mission, so should not mess anything else.
It's for the God Eater 2 Prelude Edition DEMO 2(NPJH-90342) that was linked here.

[unknownbrackets]

Is this at all improved by doing this?
https://github.com/unknownbrackets/ppsspp/compare/module-clear

It's just a theory.

-[Unknown]

[daniel229]

Sill hangs.

[CPkmn]

fwiw in v1.40 continuous missions can be done by increasing the allowed memory size. that probably means something isn't being cleared (or maybe the game doesn't recognise the clear for some reason?)

adding
{ "NPJH50832", 0x02F00000, false },
to g_HDRemasters is a "fix" (props to lunamoo) but the game shouldn't need more memory than a real PSP will normally will give it.

[sum2012]

@unknownbrackets Just a question .Do ppsspp invalidate native code blocks when unloading PSP modules ?

[LunaMoo]

@CPkmn actually this hd remaster addition is not increasing the memory, but decreasing it, as the game allocates much more(0x04000000 ?) with your other hacks in ElfReader: "vaddr = userMemory.Alloc(totalSize, true, "ELF");". and in sceKernelThread: currentStack.start = userMemory.Alloc(stackSize, true, (std::string("stack/") + nt.name).c_str());

[CPkmn]

@LunaMoo oops I meant decreasing. its 3AM when I posted that and I was tired. the updates for god eater 2 are interesting in PPSSPP. something always seem to be fixed in each update and something else breaks.

[LunaMoo]

Yeah;3, and also it's more than likely that all GE series games are affected by the problem it just doesn't break anything at least in GEB, as we can see in cwcheat.cpp:
if (gameTitle == "ULUS10563" || gameTitle == "ULJS-00351" || gameTitle == "NPJH50352" ) //Offset to make God Eater Burst codes work
address -= 0x7EF00;

^Memory is weirdly shifted in GEB as well and while that offset fixes some cheats it breaks others, because the game seems to also have messed up memory and just accidently working without problems.

[unknownbrackets]

Do ppsspp invalidate native code blocks when unloading PSP modules ?

Well, essentially yes, especially with my change, since the emuhacks are gone. To be double sure, you can add this after the memset my change adds:

currentMIPS->InvalidateICache(memoryBlockAddr, memoryBlockSize);

-[Unknown]

[sum2012]

unluck still fail

[sum2012]

PPSSPP v0.9.8-1610-gc4bebda Windows 64 bit still fail
log: https://gist.github.com/sum2012/2f038b7455dd334655a9

[unknownbrackets]

Does https://github.com/unknownbrackets/ppsspp/tree/modules help at all? It may allocate modules more correctly in memory (kernel modules in kernel memory, user modules at top/bottom.)

-[Unknown]

[daniel229]

No,it doesn't.

[unknownbrackets]

But the "fromTop" thing still does, right? Hmm.

-[Unknown]

[daniel229]

fromTop = 1;aways not help this problem.

[unknownbrackets]

Oh. I think I got it confused with #4545, then. That branch doesn't help that one either though, does it?

-[Unknown]

[daniel229]

No,it doesn't.

[daniel229]

That branch make Metal Gear Solid Portable Ops Chinese patch hangup after title,report a lot of snd_thread_m W[KERNEL]: ppsspp\Core/HLE/sceKernel.h:459 Kernel: Bad object handle -2143190986 (80418036)

[unknownbrackets]

That's not even an error code it returns, though.

-[Unknown]

[level99procrastinator]

The address is not restored correctly when unloading module.
This patch seems to work:

diff --git a/Core/HLE/sceKernelModule.cpp b/Core/HLE/sceKernelModule.cpp
index 2a542f4..ebf02c9 100644
--- a/Core/HLE/sceKernelModule.cpp
+++ b/Core/HLE/sceKernelModule.cpp
@@ -539,7 +539,14 @@ void WriteVarSymbol(u32 exportAddress, u32 relocAddress, u8 type, bool reverse =
    case R_MIPS_LO16:
        {
            // Sign extend the existing low value (e.g. from addiu.)
-           const u32 exportOffsetLo = exportAddress + (s16)(u16)(relocData & 0xFFFF);
+                        u32 exportOffsetLo = exportAddress;
+
+                        if (!reverse) {
+                                exportOffsetLo += (s16)(u16)(relocData & 0xFFFF);
+                        } else {
+                                exportOffsetLo -= (s16)(u16)(relocData & 0xFFFF);
+                        }
+
            u32 full = exportOffsetLo;

            // The ABI requires that these come in pairs, at least.

[unknownbrackets]

Nice catch. But hmm. Does that mean the reverse within the lastHI16Relocs is not correct? That will basically unreverse that check. Maybe it is wrong... hmm.

Or no wait, it won't exactly "unreverse" that, what am I saying. No, maybe it's right like this.

-[Unknown]