Someone reported a bug if pthread_detach is called while a pthread_join is
already in progress, but I'm unable to reproduce it. Keep the tests I wrote,
though.
Change-Id: I3d71450bbbb5345f2cb213dc56310ec020d528cc
first_run is only used with LOCK_AT_FORK, however, care needs to be
taken with the #if to avoid compiler warnings when LOCK_AT_FORK isn't
being used.
Change-Id: I6bcfac2ab8732c91607f4a1bcd7c0019f29c2eec
Several previous changes conspired to make a mess of the thread list
in static binaries. This was most obvious when trying to call
pthread_key_delete(3) on the main thread.
Bug: http://code.google.com/p/android/issues/detail?id=36893
Change-Id: I2a2f553114d8fb40533c481252b410c10656da2e
Add getsid() system call to bionic for
all architectures. This is needed for various tools
(e.g. perf).
Adding the getsid system call was done in 3 steps:
() add getsid system call (function name and syscall
number) to libc/SYSCALLS.TXT
() generate all necessary headers by calling
libc/tools/gensyscalls.py. This patch is adding
the generated files since the build system
does not call gensyscalls.py.
() add the system call signature to libc/include/unistd.h
Change-Id: Id69a257e13ec02e1a44085a6b217a3f19ab025b1
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Expecting the memory in a forked child process to be sane wrt threading
is a bad idea. An example of a problem is when the parent process has
the malloc lock and a child process is forked. The malloc lock in the
child will appear locked by a thread that doesn't exist.
This change aims to make bionic more compatible with glibc by reseting
the malloc lock in the child forked process, as well as holding it
during the fork. This is a feature in dlmalloc 2.8.6 called
LOCK_AT_FORK. In general this feature isn't necessary as a forked
process will then exec. Some bad applications rely on being able to use
features like malloc before the exec and having multiple threads running
in the parent program. This isn't a problem with glibc and this patch
makes it not a problem for bionic.
Unfortunately for use in bionic, LOCK_AT_FORK has an issue as internally
it uses pthread_atfork that in bionic uses malloc. This leads to the
LOCK_AT_FORK initialization deadlocking with pthread_atfork's call to
malloc due to the malloc lock. This change moves the pthread_atfork logic
in LOCK_AT_FORK to be called without the malloc lock held.
Change-Id: Id68175a564a6abb936ee4488b44d9479f7311f69
Lose the pid, only show the name of the function (not its whole signature),
and include the name of the library we failed to load. (I hadn't noticed
that the library name was missing before because in Java we add that into
the UnsatisfiedLinkError detail message.)
The new output looks like this:
Cannot load library: soinfo_relocate(linker.cpp:968): cannot locate symbol "__libc_malloc_default_dispatch" referenced by "libc_malloc_debug_leak.so"...
Change-Id: I3bb5c9780d9aaf3a9e4418ea55bc98122a81f80f
Clang and _FORTIFY_SOURCE are just plain incompatible with
each other. First of all, clang doesn't understand the
__attribute__((gnu_inline)) header. Second of all,
Clang doesn't have support for __builtin_va_arg_pack()
and __builtin_va_arg_pack_len() (see
http://clang.llvm.org/docs/UsersManual.html#c_unimpl_gcc)
Until we can resolve these issues, don't even try using
_FORTIFY_SOURCE under clang.
Change-Id: I81c2b8073bb3276fa9a4a6b93c427b641038356a
