[Android] Spider-Man 3 crashes unexpectedly

[Leopard20]

PPSSPP crashes in the first few seconds of the game. Don't know why or exactly when.

(So that search for the alternate spelling works: Spiderman 3).

[unknownbrackets]

Did this used to work in 1.4.2? Does it matter which GPU backend you use? What device? Do other games work?

Since you didn't provide any detail, we can't tell if you're using some obscure MIPS Warrior CPU or what.

Nothing can be done if you don't provide detail.

-[Unknown]

[Leopard20]

I don't have access to the game right now, so I can't test on v1.4.2. But I remember that the issue occurred on both backends. I didn't notice crashes in other games like this (this game cashed when I was playing a level without skipping any videos or using load state) but I did notice crashes in Splinter Cell Essentials on load state and Field Commander when I skipped videos.

My GPU: Adreno 530 (Snapdragon 821 chipset) I think the PPSSPP version was 1.4.2-894 or something. I'll download the game later and let you know if I find anything new.

[Leopard20]

Update: No crashes on the PC version. I only tested the OpenGL backend.

[unknownbrackets]

A few things that cause crashes have been fixed - does this still happen on the latest git build?

It'd be great to find the first build it stopped working on. For example, if you knew that 1.4.2 worked, you could test somewhere around v1.4.2-475-ged602a331. If that worked, try a newer build, if not, try an older. In 8 - 10 tests you could narrow down the change that caused it. Usually this makes it a lot easier to fix the issue.

If no previous version worked, it can be tricky.

-[Unknown]

[Leopard20]

@unknownbrackets I testesd some random builds since v1.4.2. Versions that had experimental tag for vulkan backend (such as 1.4.2-6) couldn't even run the game and crashed instantly. I didn't notice any difference between other builds. (including the most recent, 1.5.4-93) This may have been random, but I noticed enabling the speed up tricks (lazy texture caching, disabling slower effects, etc) caused the game to crash faster. Without these options I could play all the way to the point where an explosion creates a hole in the wall (before it crashed when the second bunch of thugs entered the room). But as soon as I try to move through the hole the game crashes again. I think it's because of graphical overload or something.

[Leopard20]

This log was posted by @weihuoya in the above thread: Spider-Man 3 only crash on android(JIT, IR, Interperter, and turning off fast memory)

    --------- beginning of crash
06-05 15:56:34.996 23936-23958/? A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x2300014000 in tid 23958 (Emu)
06-05 15:56:35.091 24481-24481/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-05 15:56:35.093 24481-24481/? A/DEBUG: Build fingerprint: 'samsung/hero2qltezc/hero2qltechn:7.0/NRD90M/G9350ZCU2BRD1:user/release-keys'
    Revision: '14'
    ABI: 'arm64'
06-05 15:56:35.094 24481-24481/? A/DEBUG: pid: 23936, tid: 23958, name: Emu  >>> org.ppsspp.ppsspp <<<
    signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2300014000
06-05 15:56:35.095 24481-24481/? A/DEBUG:     x0   0000007f6ccbe0f4  x1   0000000000013ffe  x2   0000007f6f19eed6  x3   000000000000005d
        x4   0000007f6f19ef7c  x5   000000000000fffe  x6   000000000000fffe  x7   0000000008a14ef0
        x8   0000002300000000  x9   0000000004000000  x10  00000000000078cc  x11  0000000000000000
        x12  0000000000000003  x13  0000000000000000  x14  0000007f6eaabc60  x15  0000000000000000
        x16  0000007f6f647a88  x17  0000007f6eab7ef8  x18  0000000000000001  x19  0000007f6ccbe0f4
        x20  0000000000013ffe  x21  0000007f6f678f30  x22  0000000000000000  x23  0000007f6f6562a8
06-05 15:56:35.096 24481-24481/? A/DEBUG:     x24  0000007f6f6c0e94  x25  0000007f6f695708  x26  afb12da5406b7b53  x27  000000000000004b
        x28  0000007f6f656000  x29  0000007f6ccbe0e0  x30  0000007f6eab7ed0
        sp   0000007f6ccbe0c0  pc   0000007f6eab7f80  pstate 0000000060000000
06-05 15:56:35.136 24481-24481/? A/DEBUG: backtrace:
        #00 pc 0000000000450f80  /data/app/org.ppsspp.ppsspp-1/lib/arm64/libppsspp_jni.so (_ZN6Memory16ReadFromHardwareIjEEvRT_j+136)
        #01 pc 0000000000450ecc  /data/app/org.ppsspp.ppsspp-1/lib/arm64/libppsspp_jni.so (_ZN6Memory8Read_U32Ej+44)
        #02 pc 000000000044d348  /data/app/org.ppsspp.ppsspp-1/lib/arm64/libppsspp_jni.so (_Z22MIPSInterpret_RunUntily+88)
        #03 pc 0000000000464398  /data/app/org.ppsspp.ppsspp-1/lib/arm64/libppsspp_jni.so (_Z14PSP_RunLoopFori+84)
        #04 pc 0000000000565c18  /data/app/org.ppsspp.ppsspp-1/lib/arm64/libppsspp_jni.so (_ZN9EmuScreen6renderEv+336)
        #05 pc 000000000061c0fc  /data/app/org.ppsspp.ppsspp-1/lib/arm64/libppsspp_jni.so (_ZN13ScreenManager6renderEv+136)
06-05 15:56:35.137 24481-24481/? A/DEBUG:     #06 pc 000000000055dc3c  /data/app/org.ppsspp.ppsspp-1/lib/arm64/libppsspp_jni.so (_Z12NativeRenderP15GraphicsContext+644)
        #07 pc 00000000005584fc  /data/app/org.ppsspp.ppsspp-1/lib/arm64/libppsspp_jni.so (_Z20UpdateRunLoopAndroidP7_JNIEnv+44)
        #08 pc 0000000000559c58  /data/app/org.ppsspp.ppsspp-1/lib/arm64/libppsspp_jni.so
        #09 pc 00000000003a16f0  /data/app/org.ppsspp.ppsspp-1/lib/arm64/libppsspp_jni.so (_ZNSt6__ndk114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_EEEEPFvvEEEEEEPvSA_+44)
        #10 pc 000000000006885c  /system/lib64/libc.so (_ZL15__pthread_startPv+196)
        #11 pc 000000000001e118  /system/lib64/libc.so (__start_thread+16)

[unknownbrackets]

It's very strange that this crashes even in the interpreter, but only on Android. Just not sure what would be different between Android and Windows that would affect CPU emulation.

To confirm, PC is fine even in interpreter and with fast memory enabled?

-[Unknown]

[weihuoya]

PC run interpreter with fast memory enabled or disabled, both assert this message.

        case 62: //sv.q
            if (addr & 0xF)
            {
                _dbg_assert_msg_(CPU, 0, "Misaligned sv.q");
            }

[unknownbrackets]

Oh, that's interesting. We definitely might not be handling misaligned sv.q the same in all jit backends...

-[Unknown]

[unknownbrackets]

Well, looking at the error more carefully - the fault is at 0x2300014000 right outside the scratchpad. So I guess it's not alignment...

Anyway, the behavior DOES differ a bit per backend:

• Interpreter: copied without alignment (at 1 byte)
• IR interpreter: stored as float * or on x86 potentially SSE aligned (may crash.)
• x86: potentially MOVAPS in fast memory but not always, otherwise unaligned.
• armv7: either 128 bit or 32 bit aligned, otherwise might crash.
• arm64: probably unaligned.

Though, I guess that's not related after all.

-[Unknown]

[ghost]

Game still crahes in the latest git build :(

[ghost]

Game still crashing Im using ppsspp v1.8.0-403 gbdd9d40a1 This is the part where the game always crashing 🤔 GE Dump for Spider-Man 3 (Europe) ULES00938_0001.ppdmp.zip

[ghost]

This game doesn't crash in ppsspp v0.9.8 https://youtu.be/_L73ZLVJEHA and also it's performing better in my phone compare to the last gitbuild 🤔 I still didn't test v1.0 - v1.4 🤷 But have a bug in FPS it's lock in 30/30 not 60/60😅

[ghost]

@unknownbrackets after several testing Spider-Man 3 didn't crash in v0.9.8 (performance better in my phone) and v0.9.9.1 (slow on my device with graphical glitches)

The game crash in area where I mentioned above tested in v1.0 - 1.4 🤔 So I what changes happen in v1.0 that make this game crash but not in v0.9.9.1?

PS: sorry for my bad english

[ghost]

PPSSPP Last Build Sample Video https://drive.google.com/file/d/1-DAgFaV7pJPyhnw4v6yNUAf0sge4kK1U/view?usp=drivesdk

PPSSPP Old Version 0.9.8 Sample Video https://drive.google.com/file/d/1-FG1Dle59JkblSxteiekpTcHAbepIzs6/view?usp=drivesdk

*Note: ppsspp v0.9.8 has better performance without screen recording in my phone (arm32/Mali-450/octacore)

[unknownbrackets]

It's possible this was caused by the hardcoded use of 0x2300000000 which was recently changed. Does this still happen in the latest git builds?

Any performance issue is separate.

-[Unknown]

[hrydgard]

@leopard20 can you test in the latest builds if this still happens for you?

[ghost]

Still crashes on my phone same area where the game always crash I'm currently using v1.8.0-583-gc8730c933 🤷

[hrydgard]

Okay that's unfortunate, but thanks for testing!

[unknownbrackets]

Can you check the CRC of your disc as well? I ask because people have reported this game as "Perfect" on mobile devices: https://report.ppsspp.org/game/ULUS10317_1.02 https://report.ppsspp.org/game/ULES00938_1.01

It seems like there are various CRCs floating around, so I just want to confirm this isn't somehow related to a bad rip. Since it's supposed to crash in the first few seconds, I imagine no one would mark it "Perfect" on mobile...

-[Unknown]

[unknownbrackets]

Also, if the white shading on spiderman in those screenshots is wrong (it sure looks wrong, or at least not great, to me?) a GE frame dump would help.

-[Unknown]

[hrydgard]

It looks to me like the white shading is actually not that far off: https://www.youtube.com/watch?v=NKV2auBUnfk

[unknownbrackets]

Ah, okay. I realized a difference between x86 and ARM - only when fast memory is disabled. We check on x86 for the read/write size, but on ARM we only check the base address.

For example, a sv.q writes 16 bytes. On x86, if I try to write 16 bytes at say 0x00013FF8, it will notice that 8 of those bytes would go outside the range, and skip it. However, on ARM, it will only notice that 0x00013FF8 is valid, and not skip anything.

So that may account for the behavior specifically when fast memory is disabled. However, a crash with fast memory enabled is a bug. So this may not be platform specific, really. I feel like this supports the theory that it's a corrupt disc.

-[Unknown]

[ghost]

PPSSPP GE Dump

Spider-Man 3 GE Dump Europe.zip

Game Details Screenshot

PPSSPP v1.8.0-585 beta build Mali-450 MP GPU MT6592 CPU Octacore

[hrydgard]

@Emulatorer Can you try your ISO file on a PC? If it crashes or shows the assert message there, it's almost certainly a broken ISO file.

[Leopard20]

@hrydgard I already tried it back when I posted this issue. It works fine on PC. Also, how can the iso be broken if it works fine on an older version (and other platform)?

[ghost]

Yes this game is working correctly in v0.9.9 or below without crashing issue 😄

The crashing issue started in v1.0 and above of ppsspp so @leopard is right my ISO is not bad rip iso or whatever 🤷

[unknownbrackets]

The problem is, there have been like twelve thousand changes in the five years since that version. It's very possible that we were emulating something wrong that "accidentally" avoided the crash in the game.

You might say: if my game is broken, but a bug in the emulator makes it run properly, isn't it not a bug? But, if it would crash on a PSP, and it breaks other games, I would argue that it really is a bug.

Also remember: fast memory being off is a hack that behaves differently on different platforms. If it only works on the latest git build on PC with fast memory turned off, that does not imply it's a good rip.

I don't have this game, so I can't check. But there are people reporting that the EU version of this game works fine, even on Mali-400, Mali-G72, PowerVR 544, or Adreno 330 devices. That's a good range, and all on v1.8.0.

Here's a screenshot one such user posted: https://report.ppsspp.org/uploads/ULES00938_1.01/compat-266027.jpg

There is definitely something funny when some users are able to play the game fine across multiple versions. Why would that happen?

You also still have not posted the CRC. I really want to know if your CRC is the same as the CRCs of the people who can play the game even on Android in latest versions without any problems.

-[Unknown]

[hrydgard]

We should probably make an easy way to see the CRC from the game info screen... that way people could verify that they have the same or correct ISO manually.

[Leopard20]

@unknownbrackets Well, mine is: CRC32: 798E7D3F CRC64: 8CAFF21CA64F89CD

I wouldn't rely too much on your "report" site though. Go take a look here: https://report.ppsspp.org/game/ULUS10317_1.02

One report (for a certain ISO) says the game is "perfect", and another says "In-game" or some other unplayable state.

Plus 99% of the screenshots you see there are captured right before the crash I mentioned here. So probably none of them actually played the game.

Perhaps there's something different about different Android ROMs that causes this. You should also make them report their Android version and ROM. Plain "Android" is meaningless.

[Leopard20]

Also, just to be safe I tried the game on both PC and Android. Nothing's changed. It works perfectly fine on PC. On Android the game crashes regardless of backend, fast-memory, etc. settings.

[unknownbrackets]

To me, the reports are pretty useful and accurate. They don't say they aren't using cheats just to later reveal that they forgot they turned on cheats and that was the cause after all (which has happened on multiple GitHub issues with information provided by humans.) They don't really fingerprint users, it's true, but the information in them is valuable for sure.

In this case, it probably means that some other factor is involved. There must be more to it. So knowing the CRC of a game that reproduces this matches both working and not working reports is very useful. Thanks.

Looking only at reports for v1.8.0 on Android with that same CRC:

"Perfect"/"Playable" reports (47%) include:

• Qualcomm (MSM8917, MSM8974PRO-AC, etc.)
• Spreadtrum (SC9850ka)
• Mediatek (MT8127)
• Samsung (UNIVERSAL3475, Exynos7580)

"Ingame"/"Menu"/"Doesn't Boot" reports (53%) include:

• Qualcomm (MSM8937, SDM66 - truncated from CPUInfo, MSM89 truncated)
• Spreadtrum (SC8830)
• Mediatek (MT6750T, MT6580, MT6750V/WS, mt6762m)

Sometimes people do indeed misreport whether the game works or not (but usually on the "doesn't boot" when it runs fine, I think there are translations that translate that to something that can be read as "I don't want to pick any status".) That said, I'm sure people select Perfect without trying that much of the game too.

Even so, the decent spread in both cases makes it seem unlikely (though not impossible) it's related to CPU vendor.

Similarly, Adreno 5xx and Mali-T8xx are common across both as well (with some other Adreno and Mali versions mixed in, and one PowerVR Rogue not working.) At least one "menu/intro" appears to be using Chainfire3D or something, though. Even the exact same driver version of Mali-T720 was reported working and not working.

People with exactly the same config settings (among reported config settings only) have also reported working and not working. Went through the settings, most settings seem to have no correlation, except:

• Rendering mode: buffered (working), buffered and non-buffered (not working)
• Texture filtering: always auto (working), auto/linear/fmv (not working)
• Internal res: auto, 1-3 (working), auto 2-5 (not working)
• IO timing method: fast or host (working), fast or UMD delays (not working)

There does seem to potentially be a correlation with IO timing method. Does it help to change it to "host"?

-[Unknown]

[Leopard20]

@unknownbrackets Actually, I noticed something funny. On Android, unthrottling causes some sort of bug, which causes the game to get stuck in a certain "splash-screen sequence", and the screen keeps flashing on and off (i.e. becomes black and then shows the splash screen in an infinite loop). I don't think this is IO-related though (but I'd say your unthrottling technique on Android needs improvement)

I've deleted the game again! I'll report back when I put it back on my phone!

[Leopard20]

@unknownbrackets Tested changing the IO method, but the game still crashes. My other settings were nearly the same as the ones that were reported as working.

[Lerianis]

Not the correct error. This is an issue with PPSSPP and we need to stop saying "It's that you have a bad rip!" when some of us like myself are using a rip of our own original PSP disk to try to play the game.

It is an actual regression with the code somewhere, not that we have a bad CRC on the disk.

I'm betting it is some DRM mechanism that PPSSPP was avoiding back in 0.9.9 and now we are not avoided it somehow.

[ghost]

Good News

Not crashing anymore in the part where I mention here https://github.com/hrydgard/ppsspp/issues/10196#issuecomment-509134212 But enemy won't disappear after beating them 🤔 EDIT: They disappear but they took to long because the lag of my phone 😅 I will play this game longer and feedback if it's crashing. But sad this game is super lag on my phone :( Also I enable Frame Duplicate to 60hz in option.

GE Dump: ULES00938_Dump.zip I'm using ppsspp v1.9.3-522 My phone specs: DevCheck-20200319-1045.txt

[ghost]

WTH 😞 it's crashing again after replaying it in that area :( Hoping this pr #11795 can help this issue 😶

[unknownbrackets]

Okay, so maybe that explains the reporting - if it only happens sometimes, maybe it's a timing problem, potentially even at the beginning of the scene that can cause the rest of the scene to be broken.

For example, we've seen issues before where if you skip videos at the beginning of a game, it makes it crash later.

-[Unknown]

[Leopard20]

@unknownbrackets I did suspect the same thing, so I didn't skip any videos or anything and the game still crashed. It doesn't seem to be a timing problem. (last I tested it, I was on v1.8.0-xxx so it may not true anymore)

[ghost]

I just want to put it here :) GE Dump The Game Running Really Slow Spider-Man III.zip

Crashlog captured by catlog app (root access require) Spider-Man III Crashlog.txt

[Fauxchief]

PPSSPP crashes in the first few seconds of the game. Don't know why or exactly when.

(So that search for the alternate spelling works: Spiderman 3).

The game crashes when in combat, I tried downloading 100% save and roamed around the city and it went perfect.. it crashed whilst i tried combating missions.. So the problem lies here

[ghost]

[deleted log that unfortunately contained nothing useful] - hrydgard

[ghost]

[deleted log that unfortunately contained nothing useful] - hrydgard

[hrydgard]

So I have a theory why this might crash on non-Windows platforms but run fine on Windows. To implement the PSP memory map, we allocate a chunk of memory and then use mmap (on other platforms) or MapViewOfFileEx (Windows) to map parts of it where we want it in address space. Unfortunately, MapViewOfFileEx's smallest increment is 65536, while the scratchpad is 16384 bytes large. mmap though can align to the smallest raw page size 4096 on most platforms.

So what I think happens is that the game writes outside the scratchpad (whether the PSP tolerates that or not I'm not sure - that determines whether it's likely to be a game bug or fallout from another emulator bug), but on Windows it simply writes to the padding area we have after to match the increment.

If my theory is correct, we could probably "fix" this on Android by mapping some extra memory to the scratchpad. But unless the PSP does tolerate writes slightly outside the scratchpad, that's a pretty ugly hack...

(really need to set up my PSP and homebrew SDK for hardware testing on my "new" machine :P)

[hrydgard]

Once build v1.9.3-995 is up on https://buildbot.orphis.net/ppsspp/index.php?m=fulllist , please give it a shot.

[ghost]

Once build v1.9.3-995 is up on https://buildbot.orphis.net/ppsspp/index.php?m=fulllist , please give it a shot.

Yes I will test it asap :)

[ghost]

@hrydgard build v1.9.3-995 is not downloadable should I download v1.9.3-996?

[hrydgard]

No, I guess I reverted it too quickly. Attempted to trigger a new build for 995.

[hrydgard]

Didn't work, I made a new commit. Look out for 997.

[hrydgard]

@Gamemulatorer It's up now.