Ys 7 crashes win-x64 emulator (Atrac failure?) #2391

Krude · 2013-06-21T22:50:15Z

Aside from the broken Minimap, the missing savegame picture and the bogus FPS problem, Ys Seven seems to have another problem. I've been playing through on PPSSPP from the start and got to the desert area.
A few minutes into the area, the emulator crashes. Strangely, it only does so on the 64 bit version of PPSSPP, which i usually use. I witnessed this a couple of times now, the first time i didn't get a log though.

I made a log of the second time this happened, where i played from my last save all the way to where the crash happened. Warning, the log is huge, it spans ~30 minutes of playing. Here's log #1: http://pastebin.com/n0T7L7DH

You can see i made a save state at 54:24:382 there. The third time, i loaded from this save state i made at the beginning of the desert area and played again until it crashed. This log is shorter, only 2 minutes until the crash. Here goes log #2: http://pastebin.com/W7T4zQA6

I then tried the x86 version of PPSSPP and loaded the same save state. No crash this time. I'll attach the log anyways for comparison. The point where the x64 version crashes is at 16:06:828 in this log. Here's log #3: http://pastebin.com/0hPkSmRC

You might have noticed it's not the most recent version i used here. So i downloaded v0.7.6-1523-gcee1bcf in x64 and tried. Crashes at the same point. Here's the log #4 from that time: http://pastebin.com/vDYXu8V9

I know, this is probably more logs than you ever wanted. You'll notice it crashes after sceAtracGetBufferInfoForReseting and before sceAtracResetPlayPosition, but only on the track that plays in the desert area. In the hugelarge log you'll see several other points where the music loops without issues.

In log #4, you'll also see that i made another save state on the recent version about ~30 seconds before the crash. I've uploaded it here: http://www27.zippyshare.com/v/59633657/file.html
(I wasn't sure what host would be best for that)

solarmystic · 2013-06-21T23:38:56Z

Thanks for the report and providing the save state for others to reproduce and diagnose the problem.

For the record, I've just downloaded your save state and tested it with 0.7.6-1523 using the x64 build to reproduce the crash.

I managed to play your save state for about 5 minutes and counting, no crashes yet.

I just ran around the desert, killing the respawning mobs, with your party.

Perhaps it takes a lot longer to repro it? I'll let the game run for another 30 minutes, like you reported in the initial crash, and report back after that time.

Funnily enough, I can hear the beginnings of a crash.. (the music goes all stuttery and all), but it doesn't actually proceed with it. The music fixes itself, and then the game goes on as usual.

unknownbrackets · 2013-06-21T23:54:58Z

Hmm. This is bad:

Mips\MIPSInt.cpp:194 BREAK!

But not all of your logs have it. Do you know when that starts appearing? I'll try to debug this sometime later. Just to confirm (I think the answer is always), does the crash only happen when using savestates, or does it always happen?

-[Unknown]

Krude · 2013-06-22T00:53:58Z

After i first experienced the crash, i played the game from my last hard save, which led to Log #1. Logs #2 & #3 were made from a loaded save state, the last one is also from a normal save.

Apart from microstutters when loading batches of new textures or decimating FBOs, which in turn stop the music momentarily, i haven't had any music stutters. Either it works flawlessly, or it crashes outright.

I'm not sure what caused the BREAK! messages or what happened during it. Due to the first crash, i had to play through a dungeon and a boss fight again to reach the desert area, and a lot of stuff happened.

PS: i tested it on the x64 version a couple of times again, loading that save state. No matter what i do, running around, just standing still or doing anything (that's not leaving the area, thus changing music) prevents the crash. It takes more or less 34 seconds from the moment of loading the state until the crash, every time.

solarmystic · 2013-06-22T00:58:40Z

@Krude

It's been an hour since I let the game run on your provided save state with the same git revision as per my previous post on this issue page.

The game has still yet to crash on me, no matter what i do with it.

A short question:- Do you have Fast Memory enabled in the options?

Krude · 2013-06-22T01:07:20Z

Hah, just after i wrote my previous comment, i actually had the idead of playing around with these options. If Fast Memory and Ignore Illegal Writes are both off, it crashes. If they are both on, it crashes, if ignore is on, and Fast Memory is off, the music cuts out for a moment, but the game continues.

I do, however, get 6MBs worth of text log messages in that short second that all say something like this:
02:42:078 SOUND_THREAD W[MM]: MemmapFunctions.cpp:91 ReadFromHardware: Invalid address 0a268984

There's 65536 of these messages, and the Invalid address is incremented by 4 bytes on each of them. I'll spare you the ridiculously large log.

unknownbrackets · 2013-06-22T01:11:04Z

The actual addresses aren't important, it's what happens right before that that is.

If possible, savedata (not a state) where it's easy to get those messages to happen (even with fast forward) would be best.

-[Unknown]

solarmystic · 2013-06-22T01:11:15Z

@Krude

Bingo. I had a hunch FastMem ON had something to do with it.

My own settings are FastMem OFF and Ignore Illegal Writes ON, which are the default settings in the ini on a fresh, unaltered PPSSPP build.

If you're on an even moderately adequate PC to begin with, you should never have to switch on Fast Mem, unless your PC is struggling in a game, as it is very Unstable and prone to crashing.

FastMem is another crutch/hack used to gain some speed for weaker mobile Android devices and extremely weaker PCs (Atom netbooks etc).

Krude · 2013-06-22T01:23:06Z

I got a hard save file here: http://www22.zippyshare.com/v/5060116/file.html
Just load it. It's already in the desert area, so you can just idle until the music loop point. It takes just over 4 minutes without fast forward.

With Ignore ON / FastMem OFF, the x86 version also stutters and trashes the log with these error messages like x64. With FastMem ON, x86 says nothing and continues without a hitch where x64 crashes outright.

Well, i can circumvent the crash now, so i can continue, i guess. I might try to get that Mips BREAK! to happen again, though.

unknownbrackets · 2013-06-22T01:43:33Z

Well, fastmem isn't really a hack, technically having it off is a hack. If fastmem crashes, the PSP would crash. Anywhere fastmem crashes means we didn't do something right and the game got confused. Fastmem crashing itself is not a bug, but whatever happened earlier that eventually caused the fastmem crash is. Well, unless a real PSP crashes/quits the game in the same situation.

It's interesting that x86 is not getting the problem with fastmem on, but it's probably just "luck." Meaning, it happens to be accessing a valid address even though it really isn't valid. Technically fastmem could overwrite random memory on your computer and even cause programs other than PPSSPP to crash (including Windows itself), I think.

Thanks for the savedata, will definitely help.

-[Unknown]

unknownbrackets · 2013-06-22T06:54:02Z

Hmm, it does crash right there. Relevant log data:

SOUND_THREAD D[HLE]: hle\scekernelthread.cpp:3003 Context switched: idle0 -> SOUND_THREAD (idle) (272 - pc: 08000000 -> 331 - pc: 08a18cc0)
SOUND_THREAD D[HLE]: hle\scekernelthread.cpp:2354 sceKernelDelayThread(100 usec)
idle0        D[HLE]: hle\scekernelthread.cpp:3003 Context switched: SOUND_THREAD -> idle0 (thread delayed) (331 - pc: 08a0590c -> 272 - pc: 08000000)
SOUND_THREAD D[HLE]: hle\scekernelthread.cpp:3003 Context switched: idle0 -> SOUND_THREAD (idle) (272 - pc: 08000000 -> 331 - pc: 08a0590c)
SOUND_THREAD D[HLE]: hle\scesas.cpp:110 sceSasGetEndFlag(ffffffff)
SOUND_THREAD D[HLE]: hle\scekernelmbx.cpp:509 sceKernelPollMbx(327, 09f9f52c): sending first queue message
SOUND_THREAD D[HLE]: hle\scekernelmbx.cpp:514 SCE_KERNEL_ERROR_MBOX_NOMSG=sceKernelPollMbx(327, 09f9f52c): no message in queue
SOUND_THREAD D[HLE]: hle\scekerneleventflag.cpp:612 sceKernelPollEventFlag(326, 00000030, 1, 09f9f528, 00000001)
SOUND_THREAD D[HLE]: hle\sceatrac.cpp:690 sceAtracDecodeData(1, 092f08c0, 09f9f534, 08c1ebc4, 08c1ebe4)
SOUND_THREAD D[HLE]: hle\scekernelthread.cpp:2354 sceKernelDelayThread(100 usec)
idle0        D[HLE]: hle\scekernelthread.cpp:3003 Context switched: SOUND_THREAD -> idle0 (thread delayed) (331 - pc: 08a06248 -> 272 - pc: 08000000)
SOUND_THREAD D[HLE]: hle\scekernelthread.cpp:3003 Context switched: idle0 -> SOUND_THREAD (idle) (272 - pc: 08000000 -> 331 - pc: 08a06248)
SOUND_THREAD D[HLE]: hle\scesas.cpp:130 sceSasCoreWithMix(08a99f80, 092f08c0, 1820, 1820)
idle0        D[HLE]: hle\scekernelthread.cpp:3003 Context switched: SOUND_THREAD -> idle0 (sas core) (331 - pc: 08a19914 -> 272 - pc: 08000000)
SOUND_THREAD D[HLE]: hle\scekernelthread.cpp:3003 Context switched: idle0 -> SOUND_THREAD (idle) (272 - pc: 08000000 -> 331 - pc: 08a19914)
SOUND_THREAD D[HLE]: hle\sceaudio.cpp:105 sceAudioOutputPannedBlocking(00000006, 00008000, 00008000, 092f08c0)
idle0        D[HLE]: hle\scekernelthread.cpp:3003 Context switched: SOUND_THREAD -> idle0 (blocking audio waited) (331 - pc: 08a18cc0 -> 272 - pc: 08000000)

...

SOUND_THREAD D[HLE]: hle\scekernelthread.cpp:3003 Context switched: idle0 -> SOUND_THREAD (idle) (272 - pc: 08000000 -> 331 - pc: 08a18cc0)
SOUND_THREAD D[HLE]: hle\scekernelthread.cpp:2354 sceKernelDelayThread(100 usec)
idle0        D[HLE]: hle\scekernelthread.cpp:3003 Context switched: SOUND_THREAD -> idle0 (thread delayed) (331 - pc: 08a0590c -> 272 - pc: 08000000)
SOUND_THREAD D[HLE]: hle\scekernelthread.cpp:3003 Context switched: idle0 -> SOUND_THREAD (idle) (272 - pc: 08000000 -> 331 - pc: 08a0590c)
SOUND_THREAD D[HLE]: hle\scesas.cpp:110 sceSasGetEndFlag(ffffffff)
SOUND_THREAD D[HLE]: hle\scekernelmbx.cpp:509 sceKernelPollMbx(327, 09f9f52c): sending first queue message
SOUND_THREAD D[HLE]: hle\scekernelmbx.cpp:514 SCE_KERNEL_ERROR_MBOX_NOMSG=sceKernelPollMbx(327, 09f9f52c): no message in queue
SOUND_THREAD D[HLE]: hle\scekerneleventflag.cpp:612 sceKernelPollEventFlag(326, 00000030, 1, 09f9f528, 00000001)
SOUND_THREAD D[HLE]: hle\sceatrac.cpp:690 sceAtracDecodeData(1, 092f28c0, 09f9f534, 08c1ebc4, 08c1ebe4)
SOUND_THREAD D[HLE]: hle\scekernelthread.cpp:2354 sceKernelDelayThread(100 usec)
idle0        D[HLE]: hle\scekernelthread.cpp:3003 Context switched: SOUND_THREAD -> idle0 (thread delayed) (331 - pc: 08a06248 -> 272 - pc: 08000000)
SOUND_THREAD D[HLE]: hle\scekernelthread.cpp:3003 Context switched: idle0 -> SOUND_THREAD (idle) (272 - pc: 08000000 -> 331 - pc: 08a06248)
SOUND_THREAD I[HLE]: hle\sceatrac.cpp:709 sceAtracGetBufferInfoForReseting(1, 1581765, 09f9f53c)
SOUND_THREAD D[HLE]: hle\scekernelsemaphore.cpp:492 sceKernelPollSema(282, 1)
SOUND_THREAD D[HLE]: hle\scekernelsemaphore.cpp:492 sceKernelPollSema(283, 1)
SOUND_THREAD W[MM]: core\memmapfunctions.cpp:91 ReadFromHardware: Invalid address 0a248944

The data it wrote in sceAtracGetBufferInfoForReseting():

0x093088c0 0x00040000 0x00000000 0x003f0000
0x00000000 0x00000000 0x00000000 0x00000000

Not sure what's wrong here... @oioitff, any of the above look wrong to you?

-[Unknown]

oioitff · 2013-06-22T08:54:30Z

Hmm, that seems fine. Maybe some functions returned a wrong value somewhere and then caused BREAK.

papel · 2013-08-05T00:52:45Z

This problem happens in Segram Desert, Holy Precincts of Wind and Well of Souls.

In 32 bit-version, it does not crash, it freezes for one or two seconds and outputs thousands of things in the log.
The log shows sceAtracGetBufferInfoForReseting followed by thousands MemmapFunctions.cpp:90 ReadFromHardware: Invalid address.

Then everything continues normally. It seems to happen when the music restarts to loop, but it does not happen again at the next time that the loop restarts.

Savegame in Precincts of Wind (wait two or three minutes)
http://forums.ppsspp.org/attachment.php?aid=6244

Log in Segram Desert.
http://forums.ppsspp.org/attachment.php?aid=6205

unknownbrackets · 2013-09-14T06:41:45Z

I'm no longer able to reproduce this, but I could before. Can anyone confirm if it's gone?

It may be the improved error codes in sceAtrac.

-[Unknown]

papel · 2013-09-14T14:28:04Z

It never crashed on 32-bit and I see no changes now.
I tested it in 0.9.1-832 on Windows 32-bits and the thousands of log outputs continue.

22:25:693 SOUND_THREAD I[ME]: HLE\sceAtrac.cpp:733 sceAtracGetBufferInfoForReseting(0, 1794617, 09f9f55c)
22:25:693 SOUND_THREAD W[MM]: MemmapFunctions.cpp:93 ReadFromHardware: Invalid address 0a1e8984
22:25:693 SOUND_THREAD W[MM]: MemmapFunctions.cpp:93 ReadFromHardware: Invalid address 0a1e8988
22:25:693 SOUND_THREAD W[MM]: MemmapFunctions.cpp:93 ReadFromHardware: Invalid address 0a1e898c
22:25:693 SOUND_THREAD W[MM]: MemmapFunctions.cpp:93 ReadFromHardware: Invalid address 0a1e8980
...
22:31:384 SOUND_THREAD W[MM]: MemmapFunctions.cpp:93 ReadFromHardware: Invalid address 0a228970
22:31:384 SOUND_THREAD I[ME]: HLE\sceAtrac.cpp:955 sceAtracResetPlayPosition(0, 1794617, 262144, 0)

unknownbrackets · 2013-09-14T14:37:50Z

Hmm, strange, I was testing on x64 where it did crash before I thought. I'll check again on x32.

-[Unknown]

unknownbrackets · 2013-09-14T15:03:29Z

Okay, it does still happen after all. The problem is that this is higher (much) than it expects:

Memory::Write_U32(atrac->first.fileoffset, bufferInfoAddr + 12);

-[Unknown]

papel mentioned this issue Aug 29, 2013

Ys seven crash ios #3466

Closed

unknownbrackets closed this as completed in cf8a3e4 Sep 15, 2013

papel mentioned this issue Oct 20, 2013

PPSSPP: Atrac3+ related issues after the merge of maxim-at3plus branch to master #4248

Closed

unknownbrackets mentioned this issue Oct 23, 2013

0.9.5 Release blocking issue list. Target 1 nov. #4139

Closed

papel mentioned this issue Oct 23, 2013

Trying to fix sceAtracGetBufferInfoForResetting #4303

Closed

papel mentioned this issue Nov 9, 2013

Fixes issue #4477 : ULUS10419 : Tenchu: Shadow Assassins hangs the emu. #4483

Merged

papel mentioned this issue Nov 21, 2013

Radiant Mythology 2 and 3 have incorrect music/voices #4595

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ys 7 crashes win-x64 emulator (Atrac failure?) #2391

Ys 7 crashes win-x64 emulator (Atrac failure?) #2391

Krude commented Jun 21, 2013

solarmystic commented Jun 21, 2013

unknownbrackets commented Jun 21, 2013

Krude commented Jun 22, 2013

solarmystic commented Jun 22, 2013

Krude commented Jun 22, 2013

unknownbrackets commented Jun 22, 2013

solarmystic commented Jun 22, 2013

Krude commented Jun 22, 2013

unknownbrackets commented Jun 22, 2013

unknownbrackets commented Jun 22, 2013

oioitff commented Jun 22, 2013

papel commented Aug 5, 2013

unknownbrackets commented Sep 14, 2013

papel commented Sep 14, 2013

unknownbrackets commented Sep 14, 2013

unknownbrackets commented Sep 14, 2013

Ys 7 crashes win-x64 emulator (Atrac failure?) #2391

Ys 7 crashes win-x64 emulator (Atrac failure?) #2391

Comments

Krude commented Jun 21, 2013

solarmystic commented Jun 21, 2013

unknownbrackets commented Jun 21, 2013

Krude commented Jun 22, 2013

solarmystic commented Jun 22, 2013

Krude commented Jun 22, 2013

unknownbrackets commented Jun 22, 2013

solarmystic commented Jun 22, 2013

Krude commented Jun 22, 2013

unknownbrackets commented Jun 22, 2013

unknownbrackets commented Jun 22, 2013

oioitff commented Jun 22, 2013

papel commented Aug 5, 2013

unknownbrackets commented Sep 14, 2013

papel commented Sep 14, 2013

unknownbrackets commented Sep 14, 2013

unknownbrackets commented Sep 14, 2013