First commit:
Revert "Revert "am be741d47: am 2f460fbe: am 73b5cad9: Merge "bionic: Fix wrong kernel_id in pthread descriptor after fork()"""
This reverts commit 06823da2f0.
Second commit:
bionic: fix atfork hanlder_mutex deadlock
This cherry-picks commit 34e89c232d
After applying the kernel_id fix, the system refused to boot up and we
got following crash log:
I/DEBUG ( 113): pid: 618, tid: 618 >>> org.simalliance.openmobileapi.service:remote <<<
I/DEBUG ( 113): signal 16 (SIGSTKFLT), code -6 (?), fault addr --------
I/DEBUG ( 113): eax fffffe00 ebx b77de994 ecx 00000080 edx 00724002
I/DEBUG ( 113): esi 00000000 edi 00004000
I/DEBUG ( 113): xcs 00000073 xds 0000007b xes 0000007b xfs 00000000 xss 0000007b
I/DEBUG ( 113): eip b7761351 ebp bfdf3de8 esp bfdf3dc4 flags 00000202
I/DEBUG ( 113): #00 eip: 00015351 /system/lib/libc.so
I/DEBUG ( 113): #01 eip: 0000d13c /system/lib/libc.so (pthread_mutex_lock)
I/DEBUG ( 113): #02 eip: 00077b48 /system/lib/libc.so (__bionic_atfork_run_prepare)
I/DEBUG ( 113): #03 eip: 00052cdb /system/lib/libc.so (fork)
I/DEBUG ( 113): #04 eip: 0009ae91 /system/lib/libdvm.so (_Z18dvmOptimizeDexFileillPKcjjb)
I/DEBUG ( 113): #05 eip: 000819d6 /system/lib/libdvm.so (_Z14dvmJarFileOpenPKcS0_PP7JarFileb)
I/DEBUG ( 113): #06 eip: 000b175e /system/lib/libdvm.so (_ZL40Dalvik_dalvik_system_DexFile_openDexFilePKjP6JValue)
I/DEBUG ( 113): #07 eip: 0011fb94 /system/lib/libdvm.so
Root cause:
The atfork uses the mutex handler_mutex to protect the atfork_head. The
parent will call __bionic_atfork_run_prepare() to lock the handler_mutex,
and need both the parent and child to unlock their own copy of handler_mutex
after fork. At that time, the owner of hanlder_mutex is set as the parent.
If we apply the kernel_id fix, then the child's kernel_id will be set as
child's tid.
The handler_mutex is a recursive lock, and pthread_mutex_unlock(&hander_mutex)
will fail because the mutex owner is the parent, while the current tid
(__get_thread()->kernel_id) is child, not matched with the mutex owner.
At that time, the handler_mutex is left in lock state.If the child wants to
fork other process after than, then it will try to lock handler_mutex, and
then be deadlocked.
Fix:
Since the child has its own copy of vm space from the the parent, the
child space's handler_mutex should be reset to the initialized state.
Change-Id: I3907dd9a153418fb78862f2aa6d0302c375d9e27
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Chenyang Du <chenyang.du@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Change-Id: Ic8072f366a877443a60fe215f3c00b3df5a259c8
This patch fixes an issue where 64-bit hreaders are incorrectly included
in kernel headers. For example, file "libc/kernel/arch-x86/asm/io.h"
incorreclty includes "io_64.h" (missing, BTW) instead of "io_32.h".
The reason is because CONFIG_X86_32 isn't considered pre-defined in
"kernel_default_arch_macros" for x86, and clean_header.py doesn't
look at it at all anyway (ie. __i386__ is also ignored, but it's
okay since x86 cross compiler defines it back)
Fixed 2 tools/*py, README.TXT, and refreshed libc/kernel headers
Change-Id: Iac834cc8b3548f055d3f2a214af36072dd679fe8
Currently Renderscript sample code RsBalls crashed on x86 when SSE2
enabled. The root cause is that the stack was not 16-byte aligned
from the beginning when the processes/threads were created, so the
RsBalls crashed when SSE2 instructions tried to access the variables
on the stack.
- For the thread created by fork():
Its stack alignment is determined by crtbegin_{dynamic, static}.S
- For the thread created by pthread_create():
Its stack alignment is determined by clone.S. __thread_entry( ) is
a standard C function. In order to have its stack be aligned with
16 byte properly, __thread_entry() needs the stack with following
layout when it is called:
layout #1 (correct)
--------------
| |
-------------- <--ESP (ECX - 20)
| ret EIP |
-------------- <--ECX - 16
| arg0 |
-------------- <--ECX - 12
| arg1 |
-------------- <--ECX - 8
| arg2 |
-------------- <--ECX - 4
| unused |
-------------- <--ECX (16-byte boundary)
But it has following layout for now:
layout #2: (incorrect)
--------------
| |
-------------- <--ESP (ECX - 16)
| unused |
-------------- <--ECX - 12
| arg0 |
-------------- <--ECX - 8
| arg1 |
-------------- <--ECX - 4
| arg2 |
-------------- <--ECX (16-byte boundary)
Fixed in this patch.
Change-Id: Ibe01f64db14be14033c505d854c73033556ddaa8
Signed-off-by: Michael Liao <michael.liao@intel.com>
Signed-off-by: H.J. Lu <hongjiu.lu@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
These are generated from the matching external/kernel-headers/original
files (from kernel/samsung android-samsung-3.0-wip).
Change-Id: I982ff6a0d522ea250c3a437f5756766fcc6c5c91
Upgrade fnmatch.c from OpenBSD version 1.13 to 1.16.
This is needed primarily to address CVE-2011-0419.
This is a straight copy from upstream's version at
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/fnmatch.c and
incorporates the following changes:
Revision 1.16:
New fnmatch(3) implementation which is not recursive.
Written and provided under BSD licence by William A. Rowe Jr.
Originally released in Apache APR-1.4.5.
Merged class matching code from r1.14 and PATH_MAX check from r1.15.
ok miod millert
Revision 1.15:
Put a limit on recursion during matching, and reject input of size greater
or equal PATH_MAX. Based on similar fix made in NetBSD.
ok miod@ millert@
Revision 1.14:
POSIX character class support for fnmatch(3) and glob(3). OK deraadt@
Version 1.14 introduced charclasses.h, which we copy unmodified
from upstream version 1.1.
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/charclass.h
Bug: 3435120
Change-Id: I45133468f0c3d439fd10eb087a1c647799f9d25b
cdefs.h: Introduce the __purefunc attribute, which allows us to mark
certain functions as being "pure".
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
Many functions have no effects except the return value and their
return value depends only on the parameters and/or global variables.
Such a function can be subject to common subexpression elimination
and loop optimization just as an arithmetic operator would be.
string.h: Mark many commently used string functions as "pure", to
allow for additional compiler optimizations.
Change-Id: I42961f90f822b6dbcbc3fd72cdbe774a7adc8785
This change will automatically post-process kernel headers
specified by device, board, and product. This will allow us
to not check in each kernel header twice, at least for the
device specific headers for now.
Change-Id: I3bb144b6535504b7c26b807daa75de495554356d
Signed-off-by: Dima Zavin <dima@android.com>
New functions:
tfind
tsearch
tdelete
twalk
tdestroy (GNU extension)
Bug fix: the current implementation for realpath would crash
if the second argument (resolved_path) is NULL.
New headers:
ar.h
search.h
Change-Id: Ib6c1e42fc186a6d597a6e5a9692b16acaa155804
After applying the kernel_id fix, the system refused to boot up and we
got following crash log:
I/DEBUG ( 113): pid: 618, tid: 618 >>> org.simalliance.openmobileapi.service:remote <<<
I/DEBUG ( 113): signal 16 (SIGSTKFLT), code -6 (?), fault addr --------
I/DEBUG ( 113): eax fffffe00 ebx b77de994 ecx 00000080 edx 00724002
I/DEBUG ( 113): esi 00000000 edi 00004000
I/DEBUG ( 113): xcs 00000073 xds 0000007b xes 0000007b xfs 00000000 xss 0000007b
I/DEBUG ( 113): eip b7761351 ebp bfdf3de8 esp bfdf3dc4 flags 00000202
I/DEBUG ( 113): #00 eip: 00015351 /system/lib/libc.so
I/DEBUG ( 113): #01 eip: 0000d13c /system/lib/libc.so (pthread_mutex_lock)
I/DEBUG ( 113): #02 eip: 00077b48 /system/lib/libc.so (__bionic_atfork_run_prepare)
I/DEBUG ( 113): #03 eip: 00052cdb /system/lib/libc.so (fork)
I/DEBUG ( 113): #04 eip: 0009ae91 /system/lib/libdvm.so (_Z18dvmOptimizeDexFileillPKcjjb)
I/DEBUG ( 113): #05 eip: 000819d6 /system/lib/libdvm.so (_Z14dvmJarFileOpenPKcS0_PP7JarFileb)
I/DEBUG ( 113): #06 eip: 000b175e /system/lib/libdvm.so (_ZL40Dalvik_dalvik_system_DexFile_openDexFilePKjP6JValue)
I/DEBUG ( 113): #07 eip: 0011fb94 /system/lib/libdvm.so
Root cause:
The atfork uses the mutex handler_mutex to protect the atfork_head. The
parent will call __bionic_atfork_run_prepare() to lock the handler_mutex,
and need both the parent and child to unlock their own copy of handler_mutex
after fork. At that time, the owner of hanlder_mutex is set as the parent.
If we apply the kernel_id fix, then the child's kernel_id will be set as
child's tid.
The handler_mutex is a recursive lock, and pthread_mutex_unlock(&hander_mutex)
will fail because the mutex owner is the parent, while the current tid
(__get_thread()->kernel_id) is child, not matched with the mutex owner.
At that time, the handler_mutex is left in lock state.If the child wants to
fork other process after than, then it will try to lock handler_mutex, and
then be deadlocked.
Fix:
Since the child has its own copy of vm space from the the parent, the
child space's handler_mutex should be reset to the initialized state.
Change-Id: I3907dd9a153418fb78862f2aa6d0302c375d9e27
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Chenyang Du <chenyang.du@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
When the dynamic linker loads a shared library into memory, it
initially allocates a chunk of memory. The memory is then carved
into smaller chunks for each LOAD region, and appropriate memory
protections applied.
Modify the initial memory allocation so that the pages are mapped
as PROT_NONE, rather than PROT_READ / PROT_EXEC. This ensures that
gaps between LOAD regions are not inadvertantly readable / executable.
(Long term, we should munmap() these gaps entirely)
Change-Id: If128a203ccc6fe12dcbbd2bfe0cf13a2045675af
After forking, the kernel_id field in the phtread_internal_t returned by pthread_self()
is incorrect --- it's the tid from the parent, not the new tid of the
child.
The root cause is that: currently the kernel_id is set by
_init_thread(), which is called in 2 cases:
(1) called by __libc_init_common(). That happens when the execv( ) is
called after fork( ). But when the zygote tries to fork the android
application, the child application doesn't call execv( ), instread, it
tries to call the Java main method directly.
(2) called by pthread_create(). That happens when a new thread is
created.
For the lead thread which is the thread created by fork(), it should
call execv() but it doesn't, as described in (1) above. So its kernel_id
will inherit the parent's kernel_id.
Fixed it in this patch.
Change-Id: I63513e82af40ec5fe51fbb69456b1843e4bc0fc7
Signed-off-by: Chenyang Du <chenyang.du@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
If we catch a fatal signal that won't automatically re-throw when
the thread resumes, re-throw it manually. (Common examples are
SIGPIPE and the SIGFPE from integer division by zero.)
Change-Id: I329e6d4db907047c555957b42cbd09c50fc808e7
This reverts commit 94a85f6636
There is a smoke test failure for Prime but Crespo/Stingray are fine. Will revert the change for now until further investigation is made.
Update wire protocol to return and process error code first.
This will make sure dns proxy operations do not stall when
an internal error happens.
Also fix a compiler warning.
Also fix a potential buffer overflow.
And use correct types (uint32_t) rather than int when reading from network.
Change-Id: I9f99c16d6fd5e9137491a4d1b293a7c78e31b9c3
This adds the thread id and name to the "Fatal signal" logging,
making it easier to track down where in process it actually crashed.
Change-Id: I17a365042b2f10b161debe98bc2e7070af055dfb
