To many file descriptor opened, maybe lead to crash
Reported by
wenyong....@alibaba-inc.com,
Feb 10 2017
|
||||||||||
Issue descriptionIn crash data we collected in UC Browser, we find sometimes the file descriptors opened up to hundreds of, even more than thousand. It easily exhausts file descriptors, even lead to crash. The reason is too many ResourceBuffer were created and lots of cache file were opened.
,
Feb 10 2017
Another list we collected in one version, the second column is the number of file descriptors used by ResourceBuffer. type count leak-file log file 722 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_vivo-X7_5.1.1_1480703737049_20161203034352_fg_jni.emg1-0-0-0_result.log file 800 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_HUAWEI-TIT-CL10_5.1_1480836906225_20161204170442_fg_jni.emg1-0-0-0_result.log file 779 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_Mi-4c_5.1.1_1480878944197_20161205054126_fg_jni.emg1-0-0-0_result.log file 754 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_OPPO-R9s_6.0.1_1480565300395_20161201131822_fg_jni.emg1-0-0-0_result.log file 591 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_vivo-Y23L_4.4.4_1480705350135_20161203045248_fg_jni.emg1-0-0-0_result.log file 805 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_OPPO-R9tm_5.1_1480851495411_20161204232944_fg_jni.emg1-0-0-0_result.log file 596 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_GT-I9502_4.3_1480710635299_20161203045015_fg_jni.emg1-0-0-0_result.log file 1705 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_C730Lw_4.4.4_1480765795962_20161203201831_fg_jni.emg1-0-0-0_result.log file 852 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_HM-NOTE-1LTETD_4.4.2_1480684591073_20161203155214_fg_jni.emg1-0-0-0_result.log file 1121 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_m2_5.1_1480930066751_20161205173751_bg_jni.emg16-9-24-0-160924_result.log file 746 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_A11_4.4.4_1480636667305_20161202201159_fg_jni.emg1-0-0-0_result.log file 672 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_MI-NOTE-LTE_6.0.1_1480866906330_20161205002402_fg_jni.emg1-0-0-0_result.log file 690 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_Le-X820_6.0.1_1480503223311_20161202181407_fg_jni.emg16-9-24-0-160924_result.log file 1110 /dev/ashmem ./UCMobile_11.2.5.884_161130141238_A31_4.4.4_1480595070955_20161201203433_fg_jni.emg1-0-0-0_result.log A complete list, please refer to the attachment.
,
Feb 10 2017
Summary: We find 1320 crashs are caused by too many ResourceBuffer one week. Caused by many cache file descriptor is more.
,
Feb 10 2017
Crash stack:
02-09 07:07:59.950 1344 1554 F libc : FORTIFY_SOURCE: FD_SET: file descriptor >= FD_SETSIZE. Calling abort().
Process Name: 'com.UCMobile'
Thread Name: 'http1'
pid: 1344, tid: 1554 >>> com.UCMobile <<<
signal 6 (SIGABRT), code -6 (?), fault addr --------
r0 00000000 r1 00000612 r2 00000006 r3 00000000
r4 d6d11db8 r5 00000006 r6 0000000b r7 0000010c
r8 d6d11694 r9 d6d11728 10 0000003c fp 00000002
ip 00000612 sp d6d115e0 lr f72f7a05 pc f731b960 cpsr 60000010
00 pc 0003b960 tgkill LINE:libc.so
01 pc 00017a01 pthread_kill LINE:libc.so
02 pc 00018667 raise LINE:libc.so
03 pc 00014e27 __libc_android_abort LINE:libc.so
04 pc 0001321c abort LINE:libc.so
05 pc 00016031 __libc_fatal LINE:libc.so
06 pc 00016047 __fortify_chk_fail LINE:libc.so
07 pc 00051add __FD_SET_chk LINE:libc.so
08 pc 0000adf5 /system/lib/libjavacrypto.so
09 pc 0000f9ef /system/lib/libjavacrypto.so
10 pc 0030230b /data/dalvik-cache/arm/system@framework@boot.oat
at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native method)
at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:323)
at com.android.org.conscrypt.OpenSSLSocketImpl.waitForHandshake(OpenSSLSocketImpl.java:638)
at com.android.org.conscrypt.OpenSSLSocketImpl.getSession(OpenSSLSocketImpl.java:802)
at com.uc.base.net.apache.HttpsConnectionApacheImpl.connect(unavailable:-1)
doHandshakeAndValidateServerCertificates
verifyServerDomainAndCertificates
closeSocketThrowException
at com.uc.base.net.apache.HttpsConnectionApacheImpl.openConnection(unavailable:-1)
at com.uc.base.net.adaptor.Connection.processSession(unavailable:-1)
getConnection
createSocketFromDnsParse
clearPipe
httpFailure
at com.uc.base.net.adaptor.ConnectionThread.run(unavailable:-1)
,
Feb 10 2017
02-09 07:07:59.950 1344 1554 F libc : FORTIFY_SOURCE: FD_SET: file descriptor >= FD_SETSIZE. Calling abort(). It is the fatal log from android logcat before crash.
,
Feb 13 2017
Hi, Is this issue related to Chrome? If so can you please provide clear steps to reproduce this issue along with Device Name / Model and OS version?
,
Feb 14 2017
Hi, I'm sorry I didn't get to the point quickly enough. UC Browser is based on the Chromium, the crash data are from online (end users). The scene to produce the issue is complicated, so we have no clear steps to reproduce.
,
Feb 14 2017
The issue belongs to the Chromium, I think it is irrelated to platform. We solution to fix this issue is to limit the number(eg: 200) of ResourceBuffer to be created and the number of cache file to be opened. Most often, it has no effect to resource load. The limit may be exceeded only when exception happened, that is we want to fix.
,
Feb 21 2017
Thank you for providing more feedback. Adding requester "rsgavara@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 1 2017
,
Mar 2 2017
@mariakhomenko, any idea of what manages resourcebuffers?
,
Mar 2 2017
No. Adding OWNERS from content/browser/loader here to comment.
,
Mar 13 2017
Cleaning up sheriffbot label "Needs-Review" label as a part of modified "Needs-Feedback" sheriffbot rule. [ref bug for cleanup 684919]
,
Apr 6 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 13 2018
+morlovich@ for the part on HttpCache holding onto many file descriptors. The attachment in #3 shows 576 file descriptors used by http cache and 1191(?) by ResourceBuffers.
,
Jun 13 2018
SimpleCache is supposed to be limited to 512 since M66 (which is newer than the report). Huh, the other bug you commented on also had someone concerned about the ashmem things.
,
Jun 13 2018
512 globally, or per SimpleCache instance? does seem unlikely we'd have too many for the media cache, admittedly.
,
Jun 13 2018
Globally.
,
Jun 25 2018
Consolidating bugs - though note, the issue is not fixed. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by wenyong....@alibaba-inc.com
, Feb 10 201779.8 KB
79.8 KB View Download