ma_device_uninit crash on Android 15 #913
Comments
|
It's actually reproducible. I open my game, wait for several hours. Resume it, crash! I'll try a debug build to see if I can get some more details. |
|
Dumping the Please correct me if I'm wrong! The crash offset /* Wake up the worker thread and wait for it to properly terminate. */
if (!ma_context_is_backend_asynchronous(pDevice->pContext)) {
ma_event_signal(&pDevice->wakeupEvent);
ma_thread_wait(&pDevice->thread); // Crash here?
}0000000000e326e0 <ma_device_uninit>:
e326e0: a9bd7bfd stp x29, x30, [sp, #-0x30]!
e326e4: a90157f6 stp x22, x21, [sp, #0x10]
e326e8: a9024ff4 stp x20, x19, [sp, #0x20]
e326ec: 910003fd mov x29, sp
e326f0: b4001100 cbz x0, 0xe32910 <ma_device_uninit+0x230>
e326f4: 91004008 add x8, x0, #0x10
e326f8: aa0003f3 mov x19, x0
e326fc: 88dffd09 ldar w9, [x8]
e32700: 34001089 cbz w9, 0xe32910 <ma_device_uninit+0x230>
e32704: 889ffd1f stlr wzr, [x8]
e32708: f9400268 ldr x8, [x19]
e3270c: f9402109 ldr x9, [x8, #0x40]
e32710: b50000a9 cbnz x9, 0xe32724 <ma_device_uninit+0x44>
e32714: f9402509 ldr x9, [x8, #0x48]
e32718: b5000069 cbnz x9, 0xe32724 <ma_device_uninit+0x44>
e3271c: f9402909 ldr x9, [x8, #0x50]
e32720: b40001a9 cbz x9, 0xe32754 <ma_device_uninit+0x74>
e32724: 91019260 add x0, x19, #0x64
e32728: 9403b81a bl 0xf20790 <pthread_mutex_lock@plt>
e3272c: 52800028 mov w8, #0x1 // =1
e32730: 91023260 add x0, x19, #0x8c
e32734: b9006268 str w8, [x19, #0x60]
e32738: 9403b842 bl 0xf20840 <pthread_cond_signal@plt>
e3273c: 91019260 add x0, x19, #0x64
e32740: 9403b818 bl 0xf207a0 <pthread_mutex_unlock@plt>
e32744: f940be60 ldr x0, [x19, #0x178]
e32748: aa1f03e1 mov x1, xzr
e3274c: 9403ace1 bl 0xf1dad0 <pthread_join@plt>
e32750: f9400268 ldr x8, [x19]
e32754: f9401508 ldr x8, [x8, #0x28]
e32758: b4000068 cbz x8, 0xe32764 <ma_device_uninit+0x84>
e3275c: aa1303e0 mov x0, x19
e32760: d63f0100 blr x8 ; This is where the crash is?
e32764: 91051260 add x0, x19, #0x144
e32768: 9403b82a bl 0xf20810 <pthread_cond_destroy@plt>
e3276c: 91047260 add x0, x19, #0x11c
e32770: 9403b804 bl 0xf20780 <pthread_mutex_destroy@plt>
e32774: 9103a260 add x0, x19, #0xe8
e32778: 9403b826 bl 0xf20810 <pthread_cond_destroy@plt>
e3277c: 91030260 add x0, x19, #0xc0
e32780: 9403b800 bl 0xf20780 <pthread_mutex_destroy@plt>
e32784: 91023260 add x0, x19, #0x8c
e32788: 9403b822 bl 0xf20810 <pthread_cond_destroy@plt>
e3278c: 91019260 add x0, x19, #0x64
e32790: 9403b7fc bl 0xf20780 <pthread_mutex_destroy@plt>
e32794: 9100e260 add x0, x19, #0x38
e32798: 9403b7fa bl 0xf20780 <pthread_mutex_destroy@plt>
e3279c: f9400268 ldr x8, [x19]
e327a0: f9402109 ldr x9, [x8, #0x40]
e327a4: b5000229 cbnz x9, 0xe327e8 <ma_device_uninit+0x108>
e327a8: f9402509 ldr x9, [x8, #0x48]
e327ac: b50001e9 cbnz x9, 0xe327e8 <ma_device_uninit+0x108>
e327b0: f9402908 ldr x8, [x8, #0x50]
e327b4: b50001a8 cbnz x8, 0xe327e8 <ma_device_uninit+0x108>
e327b8: b9400a68 ldr w8, [x19, #0x8]
e327bc: 71000d1f cmp w8, #0x3
e327c0: 54000141 b.ne 0xe327e8 <ma_device_uninit+0x108>
e327c4: 3947d268 ldrb w8, [x19, #0x1f4]
e327c8: 34000108 cbz w8, 0xe327e8 <ma_device_uninit+0x108>
e327cc: f940ee68 ldr x8, [x19, #0x1d8]
e327d0: f85f8100 ldur x0, [x8, #-0x8]
e327d4: b40000a0 cbz x0, 0xe327e8 <ma_device_uninit+0x108>
e327d8: f9410a68 ldr x8, [x19, #0x210]
e327dc: b4000068 cbz x8, 0xe327e8 <ma_device_uninit+0x108>
e327e0: f940fe61 ldr x1, [x19, #0x1f8]
e327e4: d63f0100 blr x8
e327e8: b9400a68 ldr w8, [x19, #0x8]
e327ec: 51000909 sub w9, w8, #0x2
e327f0: 7100093f cmp w9, #0x2
e327f4: 540000c8 b.hi 0xe3280c <ma_device_uninit+0x12c>
e327f8: f9400268 ldr x8, [x19]
e327fc: 91304260 add x0, x19, #0xc10
e32800: 91048101 add x1, x8, #0x120
e32804: 9403b83b bl 0xf208f0 <ma_data_converter_uninit@plt>
e32808: b9400a68 ldr w8, [x19, #0x8]
e3280c: 321f0108 orr w8, w8, #0x2
e32810: 71000d1f cmp w8, #0x3
e32814: 540000a1 b.ne 0xe32828 <ma_device_uninit+0x148>
e32818: f9400268 ldr x8, [x19]
e3281c: 9119e260 add x0, x19, #0x678
e32820: 91048101 add x1, x8, #0x120
e32824: 9403b833 bl 0xf208f0 <ma_data_converter_uninit@plt>
e32828: f943e260 ldr x0, [x19, #0x7c0]
e3282c: b40000c0 cbz x0, 0xe32844 <ma_device_uninit+0x164>
e32830: f9400269 ldr x9, [x19]
e32834: f9409d28 ldr x8, [x9, #0x138]
e32838: b4000068 cbz x8, 0xe32844 <ma_device_uninit+0x164>
e3283c: f9409121 ldr x1, [x9, #0x120]
e32840: d63f0100 blr x8
e32844: f946a660 ldr x0, [x19, #0xd48]
e32848: b40000c0 cbz x0, 0xe32860 <ma_device_uninit+0x180>
e3284c: f9400269 ldr x9, [x19]
e32850: f9409d28 ldr x8, [x9, #0x138]
e32854: b4000068 cbz x8, 0xe32860 <ma_device_uninit+0x180>
e32858: f9409121 ldr x1, [x9, #0x120]
e3285c: d63f0100 blr x8
e32860: f943da60 ldr x0, [x19, #0x7b0]
e32864: b40000c0 cbz x0, 0xe3287c <ma_device_uninit+0x19c>
e32868: f9400269 ldr x9, [x19]
e3286c: f9409d28 ldr x8, [x9, #0x138]
e32870: b4000068 cbz x8, 0xe3287c <ma_device_uninit+0x19c>
e32874: f9409121 ldr x1, [x9, #0x120]
e32878: d63f0100 blr x8
e3287c: 39461268 ldrb w8, [x19, #0x184]
e32880: 340003a8 cbz w8, 0xe328f4 <ma_device_uninit+0x214>
e32884: f9400275 ldr x21, [x19]
e32888: f94006a8 ldr x8, [x21, #0x8]
e3288c: f94092b4 ldr x20, [x21, #0x120]
e32890: f9409eb6 ldr x22, [x21, #0x138]
e32894: b4000068 cbz x8, 0xe328a0 <ma_device_uninit+0x1c0>
e32898: aa1503e0 mov x0, x21
e3289c: d63f0100 blr x8
e328a0: 910502a0 add x0, x21, #0x140
e328a4: 9403b7b7 bl 0xf20780 <pthread_mutex_destroy@plt>
e328a8: 9105a2a0 add x0, x21, #0x168
e328ac: 9403b7b5 bl 0xf20780 <pthread_mutex_destroy@plt>
e328b0: f940d2a0 ldr x0, [x21, #0x1a0]
e328b4: b40000a0 cbz x0, 0xe328c8 <ma_device_uninit+0x1e8>
e328b8: f9409ea8 ldr x8, [x21, #0x138]
e328bc: b4000068 cbz x8, 0xe328c8 <ma_device_uninit+0x1e8>
e328c0: f94092a1 ldr x1, [x21, #0x120]
e328c4: d63f0100 blr x8
e328c8: f9403aa8 ldr x8, [x21, #0x70]
e328cc: 9101e2a9 add x9, x21, #0x78
e328d0: eb09011f cmp x8, x9
e328d4: 54000061 b.ne 0xe328e0 <ma_device_uninit+0x200>
e328d8: 910382a0 add x0, x21, #0xe0
e328dc: 9403b7a9 bl 0xf20780 <pthread_mutex_destroy@plt>
e328e0: f9400260 ldr x0, [x19]
e328e4: b4000080 cbz x0, 0xe328f4 <ma_device_uninit+0x214>
e328e8: b4000076 cbz x22, 0xe328f4 <ma_device_uninit+0x214>
e328ec: aa1403e1 mov x1, x20
e328f0: d63f02c0 blr x22
e328f4: aa1303e0 mov x0, x19
e328f8: 2a1f03e1 mov w1, wzr
e328fc: 5281d602 mov w2, #0xeb0 // =3760
e32900: a9424ff4 ldp x20, x19, [sp, #0x20]
e32904: a94157f6 ldp x22, x21, [sp, #0x10]
e32908: a8c37bfd ldp x29, x30, [sp], #0x30
e3290c: 1403a5ed b 0xf1c0c0 <memset@plt>
e32910: a9424ff4 ldp x20, x19, [sp, #0x20]
e32914: a94157f6 ldp x22, x21, [sp, #0x10]
e32918: a8c37bfd ldp x29, x30, [sp], #0x30
e3291c: d65f03c0 ret |
|
Or maybe the crash is in the |
|
Looks similar to this |
|
Indeed, this might be |
|
Thanks. I wonder if this might be related to this this one: #833? Unfortunately I don't have a solution for this. I tried to replicate it without success so I'm at a bit of a loss. It feels like an AAudio bug, but it's hard to know for sure, and I don't want to prematurely brush it off either just in case it might be something on the miniaudio side. I'm not sure what to do about this. A workaround for you might be to force the OpenSL backend by either disabling the AAudio backend at compile time with |
|
I'm still trying to replicate it in Debug mode (with sample apps etc). I even tried Release mode with some additional logging, but that too made the error go away 😮💨 Let me list the clues I have so far.
The crash itself may be related to an incomplete Also, I'm not able to reproduce this using any of the Developer Options that allow you to simulate low memory etc. Since I have to wait so many hours, could it be that |
|
So let's say we don't handle |
|
Ok, I think I found it. You seem to have a double-free here. Please correct me if I'm wrong 😃
|
|
Thanks for looking into that. I'll investigate that in a bit and report back. |
|
Another clue. When leaving my game for several hours, that means I will have planty of time to connect my phone to the audio system of my car (bluetooth). Thus, it's very likely that my audio device changes while my game is "paused". |
|
Some progress. The bug is indeed reproducible with the |
|
My latest theory is that a UI thread assert (our code) caused a However, since we fixed our crash bug, the same repro steps sometimes cause the game to go silent. Incredibly hard to debug. So I'm wondering if you have any pointers. Are there any parts of I'm grasping at straws here 😛 |
|
Finally got a log. Error The error is interesting indeed. But what happened on that last line? The log string sent to Also, found a similar SDL issue: libsdl-org/SDL#4985 |
|
I'm closing in on the issue! When the app is forever silenced as described above, the last thing that happens is this: I'm adding additional logging to figure out what happens when the device is started during re-routing. I'll keep you posted! However, my theory is that this statement fails: ma_aaudio_result_t resultAA = ((MA_PFN_AAudioStream_waitForStateChange)pContext->aaudio.AAudioStream_waitForStateChange)(pStream, oldState, &actualNewState, 5000000000); /* 5 second timeout. */``` |
|
I think I have identified the bug! 🙌 When error The Not sure which threads need synchronization here ( /* Putting the device into an uninitialized state will make the worker thread return. */
ma_device__set_state(pDevice, ma_device_state_uninitialized);The You might want to have a look at |
|
I tried the algorithm in PR #916. Unfortunately, I'm still able to (quite easily) reproduce the problem of muted audio (the original crash is no more, thanks to orx/orx#115). Steps to reproduce:
It's like 50% chance that audio will be muted at this point, impossible to recover without a hard reset of the game. And no trace of a crash, just silence. It's like the MA thread was stopped and never restarted. Note that (7) above usually means that I think the original theory about |
|
I'm wondering if it could be as simple as Not sure what to try next. It would certainly help if you could reproduce it. |
|
Grasping at straws here, but... if I call the function below, the audio is forever muted. Is that expected? I'm trying to isolate the problem of re-initing miniaudio. I think the "~AudioStream(s#3) mPlayerBase strongCount = 1" log is interesting. It only appears after successful init, it seems. void MiniAudio_ReInit_Bug()
{
ma_result hResult;
/* Waits for all pending operations */
while(orxThread_GetTaskCount() != 0)
;
ma_engine_uninit(&(sstSoundSystem.stEngine));
ma_engine_config stEngineConfig;
stEngineConfig = ma_engine_config_init();
/* Here, re-init config properties as per original init logic */
hResult = ma_engine_init(&stEngineConfig, &(sstSoundSystem.stEngine)); // MA_SUCCESS
}Logcat after successful loading of miniaudio (with some custom logging): Logcat after calling MiniAudio_ReInit_Bug(): |
|
Calling my The logs are identical. |
|
So there is a difference. After re-init, no samples are read. We end up here: pFirst = ma_node_input_bus_first(pInputBus);
if (pFirst == NULL) {
return MA_SUCCESS; /* No attachments. Read nothing. */
}When calling I'm seeing this log when audio disappears: |
|
So I tried
And you will indeed see this in the logcat: |
|
From what I can tell, as soon as you get It certainly looks like the underlying |
|
This line is part of the problem! First of all, I don't understand the logic. The condition is always true... can't be right? if (!pConfig->aaudio.enableCompatibilityWorkarounds || ma_android_sdk_version() > 30)Analysis I figured it makes no sense that my device switches to legacy path just because I attach and detach my earplugs, so I tried enforcing result = ma_device_init__aaudio(pDevice, &deviceConfig, &descriptorPlayback, &descriptorCapture);Error is The fix So the question is if we need this workaround at all, or if we should remove it altogether. If you want to keep it, I suggest we change the logic to this: #ifdef MA_AAUDIO_ENABLE_COMPATIBILITY_WORKAROUNDS
if (ma_android_sdk_version() == 31)
{
// ...
}
#endifI suggest targeting Feature request result = ma_device_init__aaudio(pDevice, &deviceConfig, &descriptorPlayback, &descriptorCapture);
if (result != MA_SUCCESS) {
// Notify "ma_device_notification_type_error" so that consumer gets to know about this critical error.
// MA will never recover! Consumer must explicitly re-initialize MA when ready (e.g. some retry logic).
ma_device__on_notification_error(pDevice);
ma_device__set_state(pDevice, ma_device_state_stopped);
return result;
} |
|
PR #920 fixes at least two issues in this problem area, where audio usually gets muted. However, I did find the crash too.
It crashes here due to |
|
Thanks for all your work on investigating this. I haven't had a chance to look at your PR's just yet, but on that compatibility workaround stuff, are you saying that when I haven't put much thought into it yet, but I wonder if maybe the A quick clarification, is the crashing issue still a thing? I saw your comment about this fixing the issue: orx/orx#115, but just wanted to double check that there was no underlying miniaudio issue causing that crash (assuming the muting issue is a separate thing). |
|
I encountered four bugs in total, of which one was indeed fixed by orx/orx#115. The other three are
With all these changes, I haven't seen any crashes or "mutes" 👍 A few days of testing now. As for the workaround that I removed, it's related to AudioStreamInternal.cpp#295 where the set I remember it was hard to analyze, but with aformentioned retry logic I ended up decreasing the buffer (until nothing was left). My guess is that AAudio divided it by 2 after each run. So I removed it, and then everything worked. If you pay attention to line 340, you'll see that something happened in // Default buffer size to match Q
setBufferSize(mBufferCapacityInFrames / 2); |
|
#920 has been merged into the dev branch. I think this issue can be closed now, but feel free to reopen if necessary. |
Our game engine orx uses
miniaudio 0.11.22+ (#12a8d4e)).Running
Pixel 9 Pro, Android 15 (compileSdk 35andtargetSdk 35), I just encountered this rare crash (release build). I think I ran my game some days ago, so this is likely related to a "resume" operation whereorxtears downminiaudio. What could be the culprit here?Parts of my
logcaterror:The text was updated successfully, but these errors were encountered: