-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Comments
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] |
a0 definitely looks like a function argument here, so if you click the "RA" button you might see where it got a0 from. -[Unknown] |
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] |
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] |
Do I need enabled "On change" in breakpoint ? |
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] |
Do you mean that use the breakpoint set 09430450 ?
Watch 09430450 address in Memory Viewer ?
|
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] |
So, the values it stores, in order, are: 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] |
0x0880F81C break on many times. |
This is the s0 value on each time |
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 |
That means it jumped somewhere wrong. What does the code look like at 088a8840? I guess it's a jalr? -[Unknown] |
interpreter info log: |
@unknownbrackets
v0.9.8-980-g62aafbb Good log (install data on memstick) Hope you have idea to fix |
v1.0.1-2702-g6ddbe00 still crash |
The game of graphic is fixed. |
v1.2.2-253-g861a30a same problem |
@unknownbrackets |
Update debug log to v1.7.5-560-g624587c59 |
Has this improved since the async IO changes? -[Unknown] |
Still crash with v1.9.3-500-ge14bf3bcc and here logcat. :) |
Update the log to v1.9.3-830-g9e5be91bf |
Hm, near the end of the log:
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] |
#12945 don't help this game |
@unknownbrackets (I remove sceunitly logging) bad log: (without install data) good log: (install data) |
bad
good
|
full debug log v1.10-19-g9aab3d986: |
v1.10.3-543-ge8c2fce1b-windows-amd64 still crash |
thanks @shenweip <https://github.com/shenweip>
my harddisk has problem so that I cannot test this now
在 2020年9月12日週六 下午9:00,Henrik Rydgård <notifications@github.com> 寫道:
… Closed #6025 <#6025> via #13418
<#13418>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#6025 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQTT7CSFLAN2R64CDALYRDSFNWFXANCNFSM4AO7L2JA>
.
|
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
The text was updated successfully, but these errors were encountered: