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.

Sign up for GitHub

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

Jump to bottom

stop stream cause audioserver deadlock when headset plug in or out #1485

Closed
Jimmy198901 opened this issue Jan 25, 2022 · 5 comments
Closed

stop stream cause audioserver deadlock when headset plug in or out #1485

Jimmy198901 opened this issue Jan 25, 2022 · 5 comments
Assignees
@philburk @Jimmy198901
Labels
bug_anr bug P1 high priority

Comments

@Jimmy198901
Copy link

Android version(s): Android11
Android device(s): Redmi K40
Oboe version:
App name used for testing:
(Please try to reproduce the issue using the OboeTester or an Oboe sample.)

Short description
(Please only report one bug per Issue. Do not combine multiple bugs.)

stop stream cause audioserver deadlock when headset plug in or out

"Binder:776_5" sysTid=7558
#00 pc 000000000008694c /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28) (BuildId: e3b9452a622260bd5fa514f1cf311fdf)
#1 pc 00000000000eb674 /apex/com.android.runtime/lib64/bionic/libc.so (pthread_join+244) (BuildId: e3b9452a622260bd5fa514f1cf311fdf)
#2 pc 00000000000221f0 /system/lib64/libaaudio_internal.so (aaudio::AudioStream::joinThread(void**, long)+68) (BuildId: 8be873fe55ca87e8f987849043f211c4)
#3 pc 0000000000026024 /system/lib64/libaaudioservice.so (aaudio::AAudioServiceEndpointShared::stopStream(android::spaaudio::AAudioServiceStreamBase, int)+208) (BuildId: c5af318c4c196e3e04cf80ab4df890fd)
#4 pc 0000000000027b38 /system/lib64/libaaudioservice.so (aaudio::AAudioServiceStreamBase::stop_l()+688) (BuildId: c5af318c4c196e3e04cf80ab4df890fd)
#5 pc 000000000002c178 /system/lib64/libaaudioservice.so (aaudio::AAudioServiceStreamBase::stop()+100) (BuildId: c5af318c4c196e3e04cf80ab4df890fd)
#6 pc 000000000001c0e0 /system/lib64/libaaudioservice.so (android::AAudioService::stopStream(int)+140) (BuildId: c5af318c4c196e3e04cf80ab4df890fd)
#7 pc 000000000004002c /system/lib64/libaaudio_internal.so (android::BnAAudioService::onTransact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+1916) (BuildId: 8be873fe55ca87e8f987849043f211c4)
#8 pc 000000000004983c /system/lib64/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+232) (BuildId: 872835beec52208f2acc3f0638412f32)
#9 pc 000000000005219c /system/lib64/libbinder.so (android::IPCThreadState::executeCommand(int)+1036) (BuildId: 872835beec52208f2acc3f0638412f32)
#10 pc 0000000000051ce0 /system/lib64/libbinder.so (android::IPCThreadState::getAndExecuteCommand()+156) (BuildId: 872835beec52208f2acc3f0638412f32)
#11 pc 000000000005251c /system/lib64/libbinder.so (android::IPCThreadState::joinThreadPool(bool)+60) (BuildId: 872835beec52208f2acc3f0638412f32)
#12 pc 0000000000078664 /system/lib64/libbinder.so (android::PoolThread::threadLoop()+24) (BuildId: 872835beec52208f2acc3f0638412f32)
#13 pc 0000000000015414 /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+260) (BuildId: 4868adbd42643f4c59035cf91f86828c)
#14 pc 0000000000014cd8 /system/lib64/libutils.so (thread_data_t::trampoline(thread_data_t const*)+412) (BuildId: 4868adbd42643f4c59035cf91f86828c)
#15 pc 00000000000eb0ac /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64) (BuildId: e3b9452a622260bd5fa514f1cf311fdf)
#16 pc 000000000008b810 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: e3b9452a622260bd5fa514f1cf311fdf)

"AAudio_3" sysTid=8532
#00 pc 000000000008694c /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28) (BuildId: e3b9452a622260bd5fa514f1cf311fdf)
#1 pc 000000000008a52c /apex/com.android.runtime/lib64/bionic/libc.so (__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+144) (BuildId: e3b9452a622260bd5fa514f1cf311fdf)
#2 pc 00000000000ebe90 /apex/com.android.runtime/lib64/bionic/libc.so (NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*)+348) (BuildId: e3b9452a622260bd5fa514f1cf311fdf)
#3 pc 0000000000096768 /system/lib64/libc++.so (std::__1::mutex::lock()+8) (BuildId: e415c26e877987075e2fe7bec064f87f)
#4 pc 000000000002c130 /system/lib64/libaaudioservice.so (aaudio::AAudioServiceStreamBase::stop()+28) (BuildId: c5af318c4c196e3e04cf80ab4df890fd)
#5 pc 000000000001ec94 /system/lib64/libaaudioservice.so (aaudio::AAudioServiceEndpoint::disconnectRegisteredStreams()+244) (BuildId: c5af318c4c196e3e04cf80ab4df890fd)
#6 pc 0000000000020eb0 /system/lib64/libaaudioservice.so (aaudio::AAudioServiceEndpointCapture::callbackLoop()+2680) (BuildId: c5af318c4c196e3e04cf80ab4df890fd)
#7 pc 0000000000025990 /system/lib64/libaaudioservice.so (aaudio_endpoint_thread_proc(void*) (.cfi)+228) (BuildId: c5af318c4c196e3e04cf80ab4df890fd)
#8 pc 000000000001fce4 /system/lib64/libaaudio_internal.so (aaudio::AudioStream_internalThreadProc(void*) (.cfi)+204) (BuildId: 8be873fe55ca87e8f987849043f211c4)
#9 pc 00000000000eb0ac /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64) (BuildId: e3b9452a622260bd5fa514f1cf311fdf)
#10 pc 000000000008b810 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: e3b9452a622260bd5fa514f1cf311fdf)

bugreport as follow:

bug_report1.txt.zip

Steps to reproduce

Expected behavior

Actual behavior

Device

IMG_20220125_192913
@philburk
Copy link
Collaborator

@Jimmy198901 - thanks for the stack trace.
Is this something that just happened once, or a few times, or always?
Can you reproduce it?

@Jimmy198901
Copy link
Author

Yes，it can reproduce with high probability on this phone，almost always，This problem has also occurred on other phones，but it's hard to reproduce

@philburk philburk added bug_anr P1 high priority labels Feb 19, 2022
@philburk
Copy link
Collaborator

@Jimmy198901 - Thanks for the stack trace. I can see that the stop() thread is trying to join the thread that handles timestamps. And the timestamp has detected the disconnect and is trying to call stop(). This results in a classic deadlock.

This was fixed in master for S and was backported to R in ag/13150716, which was merged on Dec 2, 2020.
Do you have any updates available for that phone? If so please apply them.
Hopefully Redmi has included the QPR fixes.

I believe that this deadlock only occurs for shared streams. Can you open the stream with sharing mode EXCLUSIVE? You may not get EXCLUSIVE access but if you do it may help.

One thing that may help is to try to delay your call to stop. That might require adding a sleep to the error callback in Oboe. If the timestamp thread exits before you call stop then perhaps this can be avoided.

Please let me know if that helps and I can add a workaround in Oboe.

@philburk philburk closed this as completed Mar 3, 2022
@Jimmy198901
Copy link
Author

@Jimmy198901 - Thanks for the stack trace. I can see that the stop() thread is trying to join the thread that handles timestamps. And the timestamp has detected the disconnect and is trying to call stop(). This results in a classic deadlock.

This was fixed in master for S and was backported to R in ag/13150716, which was merged on Dec 2, 2020. Do you have any updates available for that phone? If so please apply them. Hopefully Redmi has included the QPR fixes.

I believe that this deadlock only occurs for shared streams. Can you open the stream with sharing mode EXCLUSIVE? You may not get EXCLUSIVE access but if you do it may help.

One thing that may help is to try to delay your call to stop. That might require adding a sleep to the error callback in Oboe. If the timestamp thread exits before you call stop then perhaps this can be avoided.

Please let me know if that helps and I can add a workaround in Oboe.

Thanks for helping to solve this problem，It really gets around that problem when try to delay call to stop

1 similar comment
@Jimmy198901
Copy link
Author

@Jimmy198901 - Thanks for the stack trace. I can see that the stop() thread is trying to join the thread that handles timestamps. And the timestamp has detected the disconnect and is trying to call stop(). This results in a classic deadlock.

This was fixed in master for S and was backported to R in ag/13150716, which was merged on Dec 2, 2020. Do you have any updates available for that phone? If so please apply them. Hopefully Redmi has included the QPR fixes.

I believe that this deadlock only occurs for shared streams. Can you open the stream with sharing mode EXCLUSIVE? You may not get EXCLUSIVE access but if you do it may help.

One thing that may help is to try to delay your call to stop. That might require adding a sleep to the error callback in Oboe. If the timestamp thread exits before you call stop then perhaps this can be avoided.

Please let me know if that helps and I can add a workaround in Oboe.

Thanks for helping to solve this problem，It really gets around that problem when try to delay call to stop

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@philburk philburk

@Jimmy198901 Jimmy198901

Labels
bug_anr bug P1 high priority
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@philburk @Jimmy198901