Skip to content
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

Dream Club Portable crash after select girl #6025

Closed
sum2012 opened this issue May 5, 2014 · 36 comments · Fixed by #13418
Closed

Dream Club Portable crash after select girl #6025

sum2012 opened this issue May 5, 2014 · 36 comments · Fixed by #13418
Milestone

Comments

@sum2012
Copy link
Collaborator

sum2012 commented May 5, 2014

v0.9.8-588-gdd10207
info log:
https://gist.github.com/sum2012/100dd16e1236c2e8d635
Debug log:
https://drive.google.com/file/d/0B3OaSdeV0L8kU2tnZ0toSXpJTWc/edit?usp=sharing

2
1

@unknownbrackets
Copy link
Collaborator

A disassembly (MIPS) from within the emulator with ignore illegal disabled would be much more helpful, but these are super hard to track down "remotely", heh.

It's probably reading the reg it's dereferencing from memory, and that memory is probably either not written yet or overwritten by something too early. So we have to find where this pointer value is coming from, since it's wrong.

-[Unknown]

@sum2012
Copy link
Collaborator Author

sum2012 commented May 5, 2014

1
Teamviewer can remotely me to debug but I don't waste your time :)

@unknownbrackets
Copy link
Collaborator

a0 definitely looks like a function argument here, so if you click the "RA" button you might see where it got a0 from.

-[Unknown]

@sum2012
Copy link
Collaborator Author

sum2012 commented May 5, 2014

clicked the "RA" button
Edit:Why I see "Invalid address" in left bottom corner?
2

@unknownbrackets
Copy link
Collaborator

Invalid address says that s1 + 0x70 is invalid. If this was the current PC, that would be bad. Here it's fine.

Anyway, "lw a0, 0x70(a0)" is where it gets a0 from. So if you double click that line (088AA64C above the jal), it'll set a breakpoint. Then if you reset the game, it should stop there and you can see what the value is of a0 that it's loading a0 from.

Once we have that value, we want to set a memory breakpoint at (that + 0x70), which is where it's loading the bad a0 pointer from. Then we'll watch where that memory is getting changed from.

-[Unknown]

@sum2012
Copy link
Collaborator Author

sum2012 commented May 5, 2014

3

(088AA64C above the jal), it'll set a breakpoint. Then if you reset the game, it should stop there and you can see what the value is of a0 that it's loading a0 from.

Then remove that breakpoint .Set new breakpoint 0x094303E0+ 0x70 = 0x09430450 ?
edit:Then restart again ?

@sum2012
Copy link
Collaborator Author

sum2012 commented May 5, 2014

The is the address (09430450) change
1
2
3
4

@unknownbrackets
Copy link
Collaborator

Oh, sorry. If you hit the breakpoint button at the top you can create a breakpoint that triggers when memory is written (that's the kind you want, uncheck read.) The kind you create in the dissasembly when double clicking is just an execute breakpoint (which won't trigger, since we're not running that code.)

0x09430450 sounds right. Definitely looks like it's getting different values.

-[Unknown]

@sum2012
Copy link
Collaborator Author

sum2012 commented May 6, 2014

Do I need enabled "On change" in breakpoint ?

@unknownbrackets
Copy link
Collaborator

I would leave it unchecked, but doesn't matter too much.

What will happen is you will run, and it will hit a memory access and stop. You can open the Memory Viewer at that address to see what the value is, and then keep hitting Go again to keep stepping through the code.

Mostly I just want to know who is setting it to this wrong value.

-[Unknown]

@sum2012
Copy link
Collaborator Author

sum2012 commented May 6, 2014

Do you mean that use the breakpoint set 09430450 ?

What will happen is you will run, and it will hit a memory access and stop

Watch 09430450 address in Memory Viewer ?
edit:No I cannot watch 09430450 address in Memory Viewer untill I set back in disassemably first

You can open the Memory Viewer at that address to see what the value is

@unknownbrackets
Copy link
Collaborator

When you click the breakpoint button, it'll let you set a breakpoint. Make sure emulation is paused when you click it. I recommend setting the size=4.

Then, just hit Go and wait for it to stop. Stop will automatically change to Go every time the game writes to that memory address. Once it has stopped again, you can switch to the memory viewer window.

It should at some point have a valid memory address in it, e.g. something like 08xxxxxx (first digit can be 0, 4, or 8... second digit can be 8, 9, A, or B.)

Edit: because it's little endian, the address 0x08801234 will look like this in the memory viewer:

34 12 80 08

-[Unknown]

@sum2012
Copy link
Collaborator Author

sum2012 commented May 6, 2014

Total 14 change
4,5,6 seem same
8,9 seem same
1
2
3
4
5
6
7
8
9
10
11
12
13
15

@unknownbrackets
Copy link
Collaborator

So, the values it stores, in order, are:
0, -1, 0, 0, 0, 0, 0x080a0b07, 0xfa2c9985, 0, 0x09430460, 0x40982419

It seems to have "gotten away with" storing 0xfa2c9985 there, which also looks invalid. My theory is that it maybe should still be 0x09430460. So, try setting a breakpoint on 0x0880F81C (a normal, execute breakpoint - this is the sw line that crashes.) When it gets there, change s0 to 0x09430460 by double clicking s0 on the left.

If that makes it work, then whatever is triggering it to write the other value (possibly too early) may be the problem.

-[Unknown]

@sum2012
Copy link
Collaborator Author

sum2012 commented May 7, 2014

0x0880F81C break on many times.
If change to "0x09430460" on each time don't work

@sum2012
Copy link
Collaborator Author

sum2012 commented May 7, 2014

This is the s0 value on each time
0x09436380
0x09436360
0x094128D0
0x09412AB0
0x094123E0
0x094125C0

@raven02
Copy link
Contributor

raven02 commented May 8, 2014

i also try to run it in interpreter mode and got this "no instruction" !

12:09:029 user_main W[MM]: MemmapFunctions.cpp:94 ReadFromHardware: Invalid address 0000fffc PC 0000fffc LR 088a8848
12:09:029 user_main E[CPU]: Mips\MIPSTables.cpp:980 Unknown instruction 9d000200 at 00010004
12:09:029 user_main E[CPU]: Mips\MIPSTables.cpp:984 no instruction :(
12:09:029 user_main E[*]: MsgHandler.cpp:54 Warning: no instruction :(

@unknownbrackets
Copy link
Collaborator

That means it jumped somewhere wrong. What does the code look like at 088a8840? I guess it's a jalr?

-[Unknown]

@sum2012
Copy link
Collaborator Author

sum2012 commented May 8, 2014

Yes jalr v0
2

@sum2012
Copy link
Collaborator Author

sum2012 commented May 8, 2014

@sum2012
Copy link
Collaborator Author

sum2012 commented Jun 1, 2014

@unknownbrackets
Thanks to ppsspp forum
http://forums.ppsspp.org/showthread.php?tid=2458&pid=84675#pid84675

game only works if you install data on memstick otherwise it will crash after hostess selection on loading screen,

v0.9.8-980-g62aafbb
bad log (no install data on memstick)
https://drive.google.com/file/d/0B3OaSdeV0L8keUVhSkRqdk9pUzQ/edit?usp=sharing

Good log (install data on memstick)
https://drive.google.com/file/d/0B3OaSdeV0L8kUmktelpva20zSWM/edit?usp=sharing

Hope you have idea to fix

@sum2012
Copy link
Collaborator Author

sum2012 commented Sep 18, 2015

v1.0.1-2702-g6ddbe00 still crash

@sum2012
Copy link
Collaborator Author

sum2012 commented Jan 21, 2016

The game of graphic is fixed.
Remain this issue:Need to do game install before start.
v1.1.1-797-gcd35684
info log (I close sceultitiy log)
https://gist.github.com/sum2012/6c94de66e1762b702395
debug log (I close sceultitiy log)
https://drive.google.com/file/d/0B3OaSdeV0L8kRlhLNExza0FPMUU/view?usp=sharing

@sum2012
Copy link
Collaborator Author

sum2012 commented Apr 4, 2016

v1.2.2-253-g861a30a same problem
I think some of ioIoctl command might be wrong
JPCSP log (work):https://gist.github.com/sum2012/6242e546754240b4d00aed5708b70f94
PPSSPP log:https://gist.github.com/sum2012/d894ad11ac64ec02ce3ef3a3579be8a2

@sum2012
Copy link
Collaborator Author

sum2012 commented Apr 4, 2016

@unknownbrackets
Just another feel from jpcsp log:
We should set register 's asyncThread 's uid in startIoAsync.
Then in AsyncThread function ,get back uid from register.
If don't exist it,delete the thread

@sum2012
Copy link
Collaborator Author

sum2012 commented Mar 12, 2019

Update debug log to v1.7.5-560-g624587c59
https://drive.google.com/file/d/1zY0EQT0SEOaHnUws-VbY_4kudLsBze8f/view?usp=sharing
disassembly
1

@unknownbrackets
Copy link
Collaborator

Has this improved since the async IO changes?

-[Unknown]

@Saramagrean
Copy link
Contributor

Still crash with v1.9.3-500-ge14bf3bcc and here logcat. :)
https://drive.google.com/open?id=1KVZc9JqUbC0uyGncBM7_KCwfXUHcN6IW

@sum2012
Copy link
Collaborator Author

sum2012 commented May 17, 2020

Update the log to v1.9.3-830-g9e5be91bf
https://drive.google.com/file/d/1O90nHYkFgDQAR65dpfNDBmIB_Rec3P2q/view?usp=sharing

@unknownbrackets
Copy link
Collaborator

Hm, near the end of the log:

sceGeListUpdateStallAddr(dlid=889192487, stalladdr=4001206c)
Starting DL execution at 00012000 - stall = 0001206c

sceGeListEnQueue(addr=09a75f00, stall=00000000, cbid=00000000, param=09fff650)
Starting DL execution at 09a75f00 - stall = 00000000
Signal without wait. signal/end: 8000 0000
Starting DL execution at 09a75f08 - stall = 00000000
Signal without wait. signal/end: 4000 0000
*crash*

I guess that means it's executing on the scratchpad? Anyway, the crash is interesting because it happens from two signals in a row - which seems weird. They're only 8 bytes apart, meaning the first signal was literally right away.

I wonder if there's some issue when the signal triggers while still on idle0 - must be from continuing execution.

-[Unknown]

@sum2012
Copy link
Collaborator Author

sum2012 commented Jul 4, 2020

#12945 don't help this game

@sum2012
Copy link
Collaborator Author

sum2012 commented Jul 4, 2020

@unknownbrackets (I remove sceunitly logging)

bad log: (without install data)
https://gist.github.com/sum2012/e64616d39dc38c75b015bf5ea035ee15

good log: (install data)
https://gist.github.com/sum2012/2fa0181ed84b3817aeb3995ed6af6381

@sum2012
Copy link
Collaborator Author

sum2012 commented Jul 4, 2020

bad

25:48:288 user_main    D[SCEIO]: hle\sceio.cpp:2208 0=sceIoPollAsync(4, 09fff4e8[0000000000000004])
25:48:288 user_main    D[SCEIO]: hle\sceio.cpp:2620 0=sceIoIoctlAsync(4, 04100001, 08a88c30[c0c80301], 16, 00000000[invalid], 0)
25:48:295 SceIoAsync   D[SCEIO]: hle\sceio.cpp:2384 Decrypting PGD DRM files
25:48:295 SceIoAsync   D[SCEIO]: hle\sceio.cpp:2730 ASYNC sceIoIoctlAsync(00000004, 04100001, 08a88c30, 00000010, 00000000, 00000000)
25:48:321 user_main    D[SCEIO]: hle\sceio.cpp:2208 0=sceIoPollAsync(4, 09fff4e8[0000000000000000])
25:48:322 user_main    I[SCEIO]: hle\sceio.cpp:2474 sceIoIoctl: Asked for start sector of file 4
25:48:355 user_main    I[SCEIO]: hle\sceio.cpp:2486 sceIoIoctl: Asked for size of file 4
25:48:388 user_main    D[SCEIO]: hle\sceio.cpp:1112 0=sceIoReadAsync(4, 098b5f00, 5408)
25:48:392 SceIoAsync   W[FILESYS]: filesystems\isofilesystem.cpp:518 Reading beyond end of file, clamping size 1024 to 144
25:48:392 SceIoAsync   D[SCEIO]: hle\sceio.cpp:2691 ASYNC 1520=sceIoReadAsync(4, 098b5f00, 1520)
25:48:421 user_main    D[SCEIO]: hle\sceio.cpp:2208 0=sceIoPollAsync(4, 09fff4e8[0000000000001520])
25:48:421 user_main    D[SCEIO]: hle\sceio.cpp:1506 sceIoClose(4)
25:48:522 user_main    W[MEMMAP]: core\memmapfunctions.cpp:93 ReadFromHardware: Invalid address 40982481 PC 0880f7f8 LR 088aa65c

good

34:00:053 user_main    D[SCEIO]: hle\sceio.cpp:2077 4=sceIoOpenAsync(ms0:/PSP/SAVEDATA/ULJS00333DAT/DAT0175.DAT, 1073741825, 0)
34:00:086 user_main    D[SCEIO]: hle\sceio.cpp:2208 0=sceIoPollAsync(4, 09fff420[0000000000000004])
34:00:086 user_main    D[SCEIO]: hle\sceio.cpp:2620 0=sceIoIoctlAsync(4, 04100001, 08a88c30[c0c80301], 16, 00000000[invalid], 0)
34:00:092 SceIoAsync   D[SCEIO]: hle\sceio.cpp:2384 Decrypting PGD DRM files
34:00:092 SceIoAsync   D[SCEIO]: hle\sceio.cpp:2730 ASYNC sceIoIoctlAsync(00000004, 04100001, 08a88c30, 00000010, 00000000, 00000000)
34:00:119 user_main    D[SCEIO]: hle\sceio.cpp:2208 0=sceIoPollAsync(4, 09fff420[0000000000000000])
34:00:120 user_main    D[SCEIO]: hle\sceio.cpp:1357 5168 = sceIoLseek(4, 0, 2)
34:00:120 user_main    D[SCEIO]: hle\sceio.cpp:1357 0 = sceIoLseek(4, 0, 0)
34:00:153 user_main    D[SCEIO]: hle\sceio.cpp:1112 0=sceIoReadAsync(4, 098b5f00, 5168)
34:00:156 SceIoAsync   D[SCEIO]: hle\sceio.cpp:2691 ASYNC 1430=sceIoReadAsync(4, 098b5f00, 1430)
34:00:185 user_main    D[SCEIO]: hle\sceio.cpp:2208 0=sceIoPollAsync(4, 09fff420[0000000000001430])
34:00:185 user_main    D[SCEIO]: hle\sceio.cpp:1506 sceIoClose(4)
34:01:066 AT3 play thr D[SCEIO]: hle\sceio.cpp:1497 4=sceIoOpen(disc0:/sce_lbn0x10d70_size0x3b824, 00000001, 00000000)
34:01:066 AT3 play thr D[SCEIO]: hle\sceio.cpp:1084 sceIoRead(4, 09bd2940, 40000): deferring result
34:01:066 user_main    W[FILESYS]: filesystems\isofilesystem.cpp:518 Reading beyond end of file, clamping size 262144 to 243748
34:01:082 AT3 play thr I[ME]: hle\sceatrac.cpp:1910 0=sceAtracSetDataAndGetID(09bd2940, 0003b824): atrac3+ stereo audio
34:01:088 AT3 play thr D[SCEIO]: hle\sceio.cpp:1497 5=sceIoOpen(disc0:/sce_lbn0x58f10_size0x2160, 00000001, 00000000)
34:01:088 AT3 play thr D[SCEIO]: hle\sceio.cpp:1084 sceIoRead(5, 09b8a900, 40000): deferring result
34:01:088 user_main    W[FILESYS]: filesystems\isofilesystem.cpp:518 Reading beyond end of file, clamping size 262144 to 8544
34:01:097 AT3 play thr I[ME]: hle\sceatrac.cpp:1910 1=sceAtracSetDataAndGetID(09b8a900, 00002160): atrac3+ mono audio

@sum2012
Copy link
Collaborator Author

sum2012 commented Jul 4, 2020

@sum2012
Copy link
Collaborator Author

sum2012 commented Sep 1, 2020

v1.10.3-543-ge8c2fce1b-windows-amd64 still crash

@sum2012
Copy link
Collaborator Author

sum2012 commented Sep 13, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants