Android bug (4)-card death of Android apps

For Android, it is inevitable to run some sub-programs. common sub-programs include quadrant (quadrant), Nant, and antu. As a system engineer, they are very disdainful about these sub-programs. This can only be an objective reference, but customers like this comparison, various factories will do more or less Optimization on this (or even cheating or direct fraud). This is not a good phenomenon. It is very exaggerated. Satellites are everywhere, producing of the RMB, we are all passive people. But here we will not talk about these things. The common program used in China is antu, but I don't know if you have found that after antu runs, it sometimes gets stuck, except for the Return key and touch operation.

When this problem occurs, the Home Key can exit and continue to run other applications, indicating that the system is still normal. Top, vmstat. There are no processes with high CPU/IO usage. PS-T: No threads in D state are found. However, <span style = "PS-t found a phenomenon:

app_47    9691  8787  610076 28768 ffffffff 2aac4424 S com.antutu.ABenchMarkapp_47    9706  9691  609060 24476 80061b00 2aac5434 S com.antutu.ABenchMark

A process with the same name is displayed! This is strange ~
View the parent processes of these two processes. One is zygote and the other is com. antutu. abenchmark. From this we can infer that the last process is from the previous process fork, and it gets stuck before the fork can get Exec.

Connect to ADB and check the status of the two processes:

Process: 9691(gdb) bt#0  read () at bionic/libc/arch-mips/syscalls/read.S:13#1  0x2ad6d7d0 in executeProcess (env=0x1c7e60, javaCommands=0x2c118ab8, javaEnvironment=0x0, javaWorkingDirectory=0x0, inDescriptor=0x2c118af0, outDescriptor=0x2c118b00,     errDescriptor=0x2c118b10, redirectErrorStream=0 '\000') at libcore/luni/src/main/native/java_lang_ProcessManager.cpp:165#2  ProcessManager_exec (env=0x1c7e60, javaCommands=0x2c118ab8, javaEnvironment=0x0, javaWorkingDirectory=0x0, inDescriptor=0x2c118af0, outDescriptor=0x2c118b00,     errDescriptor=0x2c118b10, redirectErrorStream=0 '\000') at libcore/luni/src/main/native/java_lang_ProcessManager.cpp:240#3  0x2b8cccc4 in call_it () at external/libffi/src/mips/o32.S:145#4  0x0026eb78 in ?? ()

Nothing special. It is indeed stuck in the fork of process.

Let's take a look at process 9706.

(gdb) info thread* 1 Thread 9706  __futex_syscall4 () at bionic/libc/arch-mips/bionic/atomics_mips.S:218(gdb) bt#0  __futex_syscall4 () at bionic/libc/arch-mips/bionic/atomics_mips.S:218#1  0x2aabc288 in _normal_lock (mutex=0x2ab2142c) at bionic/libc/bionic/pthread.c:951#2  pthread_mutex_lock (mutex=0x2ab2142c) at bionic/libc/bionic/pthread.c:1041#3  0x2aabf848 in dlmalloc (bytes=4096) at bionic/libc/bionic/dlmalloc.c:4261#4  0x2aace004 in __smakebuf (fp=0x2ab21598) at bionic/libc/stdio/makebuf.c:62#5  0x2aad4658 in __swsetup (fp=0x2ab21598) at bionic/libc/stdio/wsetup.c:73#6  0x2aace6a0 in putc_unlocked (c=48, fp=<value optimized out>) at bionic/libc/stdio/putc.c:46#7  0x2aace744 in putc (c=48, fp=0x2ab21598) at bionic/libc/stdio/putc.c:64#8  0x2aae44c0 in cpuacct_add (uid=<value optimized out>) at bionic/libc/bionic/cpuacct.c:55#9  0x2aae57b0 in fork () at bionic/libc/bionic/fork.c:57#10 0x2ad6d764 in executeProcess (env=0x1c7e60, javaCommands=0x2c118ab8, javaEnvironment=0x0, javaWorkingDirectory=0x0, inDescriptor=0x2c118af0, outDescriptor=0x2c118b00,     errDescriptor=0x2c118b10, redirectErrorStream=0 '\000') at libcore/luni/src/main/native/java_lang_ProcessManager.cpp:92#11 ProcessManager_exec (env=0x1c7e60, javaCommands=0x2c118ab8, javaEnvironment=0x0, javaWorkingDirectory=0x0, inDescriptor=0x2c118af0, outDescriptor=0x2c118b00,     errDescriptor=0x2c118b10, redirectErrorStream=0 '\000') at libcore/luni/src/main/native/java_lang_ProcessManager.cpp:240#12 0x2b8cccc4 in call_it () at external/libffi/src/mips/o32.S:145#13 0x0026eb78 in ?? ()(gdb)

We can see that it is stopped in Bionic's fork. The specific function is: fprintf in cpuacct_add (getuid. The cause of the error is determined by Bt, and it is also a lock problem.

After finding the cause of the problem, I did not spend any effort to solve the problem. I simply Googled the problem and solution:

https://code.google.com/p/android/issues/detail?id=19916

Comment 1 by gabrb...@gmail.com, Nov 23, 2011This issue has also been found on ICS.  cpuacct_add should not be doing anything that calls malloc() or free().  Proposed fixes are here:

http://review.omapzoom.org/16579http://review.omapzoom.org/16573

Nowadays, more and more APK will secretly fork processes, execute commands in the system or dump debugging information, or even like Skype. It is not very nice to look at many native services written by fork.