| Age | Commit message (Collapse) | Author | 
|---|
|  | For some rarely cases(almost App bugs), calling malloc with
a very largre size, checked_request2size check will fail,set
ENOMEM, and return 0 to caller.
But this will let __malloc_lock futex locked and owned by the
caller. In multithread circumstance, other thread calling
malloc/calloc will NOT succeed and get locked.
Signed-off-by: Zhiqiang Zhang <zhangzhiqiang.zhang@huawei.com>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> | 
|  | Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> | 
|  |  | 
|  |  | 
|  | things, and avoid potential deadlocks caused when a thread holding a uClibc
internal lock get canceled and terminates without releasing the lock.  This
change also provides a single place, bits/uClibc_mutex.h, for thread libraries
to modify to change all instances of internal locking. | 
|  |  | 
|  | most of global data relocations are back | 
|  |  | 
|  | is a useless attempt | 
|  | test wont fail | 
|  | Only use MAP_SHARED when mmu-less. | 
|  | Lea.  It is about 2x faster than the old malloc-930716, and behave itself much
better -- it will properly release memory back to the system, and it uses a
combination of brk() for small allocations and mmap() for larger allocations.
 -Erik |