[GH-ISSUE #2391] Ys 7 crashes win-x64 emulator (Atrac failure?)

kerem commented

2026-03-17 17:49:00 +03:00

Owner

Originally created by @Krude on GitHub (Jun 21, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/2391

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)

Originally created by @Krude on GitHub (Jun 21, 2013). Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/2391 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)

kerem

2026-03-17 17:49:00 +03:00

closed this issue
added the
Atrac3+
label

kerem commented

2026-03-17 17:49:18 +03:00

Author

Owner

@solarmystic commented on GitHub (Jun 21, 2013):

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.

@solarmystic commented on GitHub (Jun 21, 2013): 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.

kerem commented

2026-03-17 17:49:23 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Jun 21, 2013):

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]

@unknownbrackets commented on GitHub (Jun 21, 2013): 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]

kerem commented

2026-03-17 17:49:28 +03:00

Author

Owner

@Krude commented on GitHub (Jun 22, 2013):

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.

@Krude commented on GitHub (Jun 22, 2013): 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.

kerem commented

2026-03-17 17:49:33 +03:00

Author

Owner

@solarmystic commented on GitHub (Jun 22, 2013):

@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?

@solarmystic commented on GitHub (Jun 22, 2013): @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?

kerem commented

2026-03-17 17:49:39 +03:00

Author

Owner

@Krude commented on GitHub (Jun 22, 2013):

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.

@Krude commented on GitHub (Jun 22, 2013): 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.

kerem commented

2026-03-17 17:49:44 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Jun 22, 2013):

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]

@unknownbrackets commented on GitHub (Jun 22, 2013): 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]

kerem commented

2026-03-17 17:49:49 +03:00

Author

Owner

@solarmystic commented on GitHub (Jun 22, 2013):

@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).

@solarmystic commented on GitHub (Jun 22, 2013): @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).

kerem commented

2026-03-17 17:49:54 +03:00

Author

Owner

@Krude commented on GitHub (Jun 22, 2013):

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.

@Krude commented on GitHub (Jun 22, 2013): 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.

kerem commented

2026-03-17 17:49:59 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Jun 22, 2013):

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 commented on GitHub (Jun 22, 2013): 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]

kerem commented

2026-03-17 17:50:04 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Jun 22, 2013):

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]

@unknownbrackets commented on GitHub (Jun 22, 2013): 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]

kerem commented

2026-03-17 17:50:09 +03:00

Author

Owner

@oioitff commented on GitHub (Jun 22, 2013):

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

@oioitff commented on GitHub (Jun 22, 2013): Hmm, that seems fine. Maybe some functions returned a wrong value somewhere and then caused BREAK.

kerem commented

2026-03-17 17:50:14 +03:00

Author

Owner

@papel commented on GitHub (Aug 5, 2013):

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

@papel commented on GitHub (Aug 5, 2013): 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

kerem commented

2026-03-17 17:50:19 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 14, 2013):

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]

@unknownbrackets commented on GitHub (Sep 14, 2013): 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]

kerem commented

2026-03-17 17:50:25 +03:00

Author

Owner

@papel commented on GitHub (Sep 14, 2013):

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)

@papel commented on GitHub (Sep 14, 2013): 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) ```

kerem commented

2026-03-17 17:50:30 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 14, 2013):

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

-[Unknown]

@unknownbrackets commented on GitHub (Sep 14, 2013): Hmm, strange, I was testing on x64 where it did crash before I thought. I'll check again on x32. -[Unknown]

kerem commented

2026-03-17 17:50:35 +03:00

Author

Owner

@unknownbrackets commented on GitHub (Sep 14, 2013):

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]

@unknownbrackets commented on GitHub (Sep 14, 2013): 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]

Rows
Columns

[GH-ISSUE #2391] Ys 7 crashes win-x64 emulator (Atrac failure?) #908