android 100 p,100% CPU usage when connection is lost on Android

I have been compiling and running retroshare-service with libupnp-1.8.4 and libupnp-1.6.21 on Android.

When the connection is available there are no problem, but if I turn off Wifi while the application is already running, so the only interface available remain lo (127.0.0.1) one of the threads of retroshare-service start eating the CPU. When reactivating the Wifi retroshare keeps working but that thread keep staying crazy.

At first I suspected RetroShare code, but while investigating with gdb I was always seeing the same thread looping like there was no tomorrow at

(gdb) bt

#0 0x000000713052f144 in __accept4 () from /home/gio/Builds/RetroShare-Android_for_arm64_v8a_Clang_Qt_5_12_4_android_arm64_v8a-Debug/libc.so

#1 0x000000712e29b0d4 in ?? ()

#2 0x746e656d75677261 in ?? ()

That didn't help much, but after many tries to interrupt the execution in an hopefully more useful point I got this

(gdb) bt

#0 0x000000713052f2f4 in __pselect6 () from /home/gio/Builds/RetroShare-Android_for_arm64_v8a_Clang_Qt_5_12_4_android_arm64_v8a-Debug/libc.so

#1 0x00000071304eb79c in select () from /home/gio/Builds/RetroShare-Android_for_arm64_v8a_Clang_Qt_5_12_4_android_arm64_v8a-Debug/libc.so

#2 0x0000007094a6dea8 in ?? () from /home/gio/Builds/RetroShare-Android_for_arm64_v8a_Clang_Qt_5_12_4_android_arm64_v8a-Debug/android-build/libs/arm64-v8a/libretroshare-service.so

#3 0x0000007094f0c410 in gMiniServerThreadPool ()

from /home/gio/Builds/RetroShare-Android_for_arm64_v8a_Clang_Qt_5_12_4_android_arm64_v8a-Debug/android-build/libs/arm64-v8a/libretroshare-service.so

Looking for gMiniServerThreadPool I found it is from libupnp which retroshare-service is using for port forwarding, I have been investigating and found this very old entry in libupnp-1.6.2 change-log that might be related

2007-11-09 Marcelo Jimenez

* Added a isleep() call to the error handler of select() in

RunMiniServer(), so that it does not take 100% cpu in case select()

fails repeatedly.

I have also tested with libupnp-1.6.21 both on Android and Gentoo with exact same retroshare-service code and exact same situation. I can reproduce the same exact behavior on Android (100% CPU again) but cannot reproduce the issue on Gentoo.

here the back traces with libupnp-1.6.21

The poor one

(gdb) bt

#0 0x000000713052f144 in __accept4 () from /home/gio/Builds/RetroShare-Android_for_arm64_v8a_Clang_Qt_5_12_4_android_arm64_v8a-Debug/libc.so

#1 0x000000712e29b0d4 in ?? ()

#2 0x746e656d75677261 in ?? ()

The one which point to libupnp again

(gdb) bt

#0 0x000000713052f2f4 in __pselect6 () from /home/gio/Builds/RetroShare-Android_for_arm64_v8a_Clang_Qt_5_12_4_android_arm64_v8a-Debug/libc.so

#1 0x00000071304eb79c in select () from /home/gio/Builds/RetroShare-Android_for_arm64_v8a_Clang_Qt_5_12_4_android_arm64_v8a-Debug/libc.so

#2 0x0000007094a9f6a4 in ?? () from /home/gio/Builds/RetroShare-Android_for_arm64_v8a_Clang_Qt_5_12_4_android_arm64_v8a-Debug/android-build/libs/arm64-v8a/libretroshare-service.so

#3 0x0000007094f3f050 in gMiniServerThreadPool ()

from /home/gio/Builds/RetroShare-Android_for_arm64_v8a_Clang_Qt_5_12_4_android_arm64_v8a-Debug/android-build/libs/arm64-v8a/libretroshare-service.so

I hope this report is helpful to solve the issue, and thanks for sharing this library with the community!