Views: 9,458,870 Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 10-05-24 10:21 AM
Guest:

0 users reading DSi sound app data-abort: notes | 1 bot

Main - Development - DSi sound app data-abort: notes Hide post layouts | New reply


Arisotura
Posted on 10-07-22 07:25 PM (rev. 15 of 10-08-22 10:30 PM) Link | #5575
ARM9: data abort (0205F998)


the pointer at 020DD088 is NULL.

it is supposed to be initialized by another thread before the data-aborting code runs, but for whatever reason it's not happening.


BASIC FLOW of how things go, and why it shits itself


* function at 02008C28 initializes shit


first call, 0200C060, eventually starts the thread at 02011348 (thread that leads to the faulty memory access). at this point, the thread is started, but not run yet, but it's marked as ready to run.


second call, 0205EB1C, initializes the object whose pointer is stored at 020DD088. except:

it first allocates the memory for that object (0xF0 bytes)

then it calls the function at 0205EB5C, that does a lot of things

then it stores the allocated pointer to 020DD088 (after 0205EB5C is done).


* 0205EB5C

does a bunch of shit

eventually calls 020EFF64, which sends a request to the ARM7 to see whether headphones are connected. that function interacts with some thread sync/messaging objects. it eventually waits for a message indicating completion of the request (ie when the ARM7 responds), which triggers a reschedule.

WHICH IS WHEN THINGS GO WRONG.

basically, the thread at 02011348 runs, because it's ready to run and none of the higher-priority threads are ready to run.

that thread also tries sending a request to the ARM7, but that doesn't happen because there's already a request underway.

then it calls 02011308.

02011308 tries to use the pointer stored at 020DD088, except at this time it's not initialized yet, so it reads from NULL+xx, which crashes.


--


so, possible ways to avoid the crash on real hardware:

1. the ARM7 answers the IPC request so quick that, on the ARM9, the response wait returns immediately and doesn't trigger a reschedule
2. the reschedule happens, but another thread with higher priority is ready to run at that time, and runs instead of the 'wrong' thread


so: plans

hook code at 0205EC48, to inspect the thread list, see which thread is the first to be ready to run at that point, output that information somehow

see if it's different on hardware

THREAD LIST: linked list, pointer to list head at 020EC2A0, pointer to current thread at 020EC284

thread entry:
0x40: inited to entrypoint+4, perhaps current thread PC
0x64: status: 1=ready to run
0x68: pointer to next thread
0x70: priority, lower value=higher prio, but the linked list is already sorted to have higher-prio threads first

ARM7 thread entry:
0x48: status
0x4C: pointer to next thread
0x54: priority

ARM7 thread list head pointer at 037FFBDC.

THREAD LIST AT THE AFOREMENTIONED POINT, BEFORE THE RESCHEDULE:

THREAD LIST:
0: ENTRY=0209FEA4 STATUS=0 PRIO=3 NEXT=020EA8A8
1: ENTRY=0209FEA4 STATUS=0 PRIO=4 NEXT=020E8010
2: ENTRY=0209FEA4 STATUS=0 PRIO=10 NEXT=0288201C
3: ENTRY=0200FCE8 STATUS=0 PRIO=11 NEXT=020EC368
4: ENTRY=0209FEA4 STATUS=1 PRIO=16 NEXT=028A93B4
5: ENTRY=0201120C STATUS=1 PRIO=19 NEXT=02881A68
6: ENTRY=0200FF3C STATUS=1 PRIO=20 NEXT=02844104
7: ENTRY=0200CF7C STATUS=1 PRIO=22 NEXT=0232CAF8
8: ENTRY=0200CB4C STATUS=1 PRIO=24 NEXT=02388778
9: ENTRY=02009604 STATUS=1 PRIO=26 NEXT=028AD658
10: ENTRY=02062AE4 STATUS=1 PRIO=28 NEXT=020EC2A8
11: ENTRY=020A1DBC STATUS=1 PRIO=32 NEXT=00000000

the problematic thread is the one with PRIO=19 (ie #5 here).

RESULT ON HARDWARE:

at that point, the next thread that will be able to run is the one with prio=19, ie. same as on melonDS. so we can rule out hypothesis 2.

which means this is a timing issue of some sort.


FIFO traffic before the crash:

IPC 9->7 3F800018
IPC 9->7 00044005
IPC 7->9 00244005
IPC 9->7 00048005
IPC 7->9 00248005
IPC 9->7 801843C8
IPC 9->7 40400048
IPC 7->9 C0384148
IPC 9->7 801843C8
IPC 9->7 40400088
IPC 7->9 C0384048
SHITPISS 00000000 02011344
ARM9: data abort (0205F998)
unknown ARM7 IO write16 04004C00 0000 037C8BB8
IPC 7->9 3F800018

first one is the 'read headphone status' request sent to the ARM7

you can see that other crap is sent in the meantime, and the ARM7 is taking a while to answer the first request



THREAD LIST ON ARM7 before the first RTC command is passed to the RTC thread:
ARM7 THREAD LIST:
[037E8BA0] 0: ENTRY=00000000 STATUS=0 PRIO=1 NEXT=03801684
[03801684] 1: ENTRY=00000000 STATUS=0 PRIO=2 NEXT=037FFFEC
[037FFFEC] 2: ENTRY=00000000 STATUS=0 PRIO=6 NEXT=037E8968
[037E8968] 3: ENTRY=00000000 STATUS=0 PRIO=7 NEXT=02FD4FF0
[02FD4FF0] 4: ENTRY=00000000 STATUS=0 PRIO=7 NEXT=02FD8B44
[02FD8B44] 5: ENTRY=00000000 STATUS=0 PRIO=8 NEXT=02FEABE4
[02FEABE4] 6: ENTRY=00000000 STATUS=0 PRIO=8 NEXT=037E88C4
[037E88C4] 7: ENTRY=00000000 STATUS=0 PRIO=9 NEXT=02FD3F4C
[02FD3F4C] 8: ENTRY=00000000 STATUS=0 PRIO=9 NEXT=02FE2608
[02FE2608] 9: ENTRY=00000000 STATUS=0 PRIO=9 NEXT=037F1EDC
[037F1EDC] 10: ENTRY=00000000 STATUS=0 PRIO=10 NEXT=02FE26AC
[02FE26AC] 11: ENTRY=00000000 STATUS=0 PRIO=10 NEXT=03801B84
[03801B84] 12: ENTRY=00000000 STATUS=0 PRIO=10 NEXT=03804104
[03804104] 13: ENTRY=00000000 STATUS=0 PRIO=12 NEXT=02FECD0C -- RTC THREAD that handles IPC 0x5
[02FECD0C] 14: ENTRY=00000000 STATUS=0 PRIO=12 NEXT=038026FC
[038026FC] 15: ENTRY=00000000 STATUS=1 PRIO=14 NEXT=03802180 -- SOUND THREAD that handles IPC 0x18
[03802180] 16: ENTRY=00000000 STATUS=0 PRIO=15 NEXT=037FFD10
[037FFD10] 17: ENTRY=00000000 STATUS=1 PRIO=16 NEXT=037FFC6C
[037FFC6C] 18: ENTRY=00000000 STATUS=1 PRIO=32 NEXT=00000000


so, what's happening on the ARM7 side:

* the IPC-18 request is received (the one to get the headphone-connected status)
* while it is being dealt with, the IPC-5 request (RTC) is received
* once these two are dealt with, it first runs the RTC thread, because it has priority
* (another IRQ is triggered, which seems spurious)
* then it goes to the sound thread, but at this point it has already received another IPC request from the ARM9, and that takes priority
* etc

so basically the ARM9 is sending its requests too fast

setting kCodeCacheTiming to 9 or more fixes the issue. (or it can be set to 8 if kDataCacheTiming is 8 for example... data plays a role in this, but code is the most important)

____________________
Kuribo64


Main - Development - DSi sound app data-abort: notes Hide post layouts | New reply

Page rendered in 0.063 seconds. (2048KB of memory used)
MySQL - queries: 27, rows: 74/74, time: 0.041 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.