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 |
| ||
Big fire melon magical melon girl Level: 58 Posts: 850/941 EXP: 1513276 Next: 64270 Since: 03-28-17 From: France Last post: 30 days ago Last view: 1 day ago |
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. Acmlmboard 2.064 (2018-07-20) © 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |