src-test2/lib/libc/stdlib, branch releng/7.3

MFC r185514 (by jasone):

2009-05-03T17:51:38Z

Fix a lock order reversal bug that could cause deadlock during fork(2). Reported and tested by: makc Approved by: re (kensmith)

Mostly synchronize lib/libthr and sys/kern/kern_umtx.c with the code

2009-03-24T20:57:10Z

from HEAD. Since libkse is still built on RELENG_7, pthread_cleanup_push/pop are left as the functions, but the support code in libthr is present for the macro versions. Malloc in RELENG_7 does not require thread exit hook, but I decided to add empty handler for it, instead of removing callback from thr_exit(). No mergeinfo since this change is prepared by patching libthr and then bringing in required missed bits. Requested by: bms Reviewed by: davidxu Tested by: bms, Mykola Dzham Approved by: re (kensmith)

MFC:

2008-11-10T17:30:49Z
Revert to preferring mmap(2) over sbrk(2) when mapping memory, due to potential extreme contention in the kernel for multi-threaded applications on SMP systems. Approved by: re (kib)

MFC r183565:

2008-10-26T21:55:19Z
Small cleanups to openpty(). - Pass O_NOCTTY to posix_openpt(2). This makes the implementation work consistently on implementations that make the PTY the controlling TTY by default. - Call unlockpt() before opening the slave device. POSIX mentions that de slave device should only be opened after grantpt() and unlockpt() have been called. - Replace some redundant code by a label. As a safety net, add a call to revoke() to unlockpt(). All applications out there use openpty(), explicitly call revoke() or implement their own PTY allocation routines. Adding the call to unlockpt() won't hurt, but will prevent foot-shooting. Reviewed by: jhb, kib Approved by: re

MFC allocator improvements and fixes:

2008-08-16T20:14:21Z
* Enhance the chunk map to support run coalescing, and substantially reduce the number of red-black tree operations performed. * Remove unused code. * Fix arena_run_reg_dalloc() to use the entire precomputed division table. * Improve lock preemption performance for hyperthreaded CPUs.

MFC: r181150, r181266

2008-08-08T00:49:28Z
Detect if the application has cleared the environ variable by setting the first value (environ[0]) to NULL. This is in addition to the current detection of environ being replaced, which includes being set to NULL. Without this fix, the environment is not truly wiped, but appears to be by getenv() until an *env() call is made to alter the enviroment. This change is necessary to support those applications that use this method for clearing environ such as Dovecot and Postfix. Applications such as Sendmail and the base system's env replace environ (already detected). While neither of these methods are defined by SUSv3, it is best to support them due to historic reasons and in lieu of a clean, defined method. Add extra units tests for clearing environ using four different methods: 1. Set environ to NULL pointer. 2. Set environ[0] to NULL pointer. 3. Set environ to calloc()'d NULL-terminated array. 4. Set environ to static NULL-terminated array. Noticed by: Timo Sirainen Reviewed by: ache

MFC r180323:

2008-07-11T09:40:14Z
- remove superfluous word - remove contractions

MFC r180325 and r180329:

2008-07-11T09:35:20Z
- This code was intially obtained from NetBSD, but it's missing licence statement. Add the one from the current NetBSD version. - Add description about a missing return value [1] PR: docs/75995 Submitted by: Tarc

MFC rev. 180024:

2008-06-30T09:16:22Z
- Mark the section describing return values with an appropriate section flag. PR: docs/122818

MFC allocator improvements and fixes:

2008-06-16T23:42:05Z
* Implement more compact red-black trees, thus reducing memory usage by ~0.5-1%. * Add a separate tree to track dirty-page-containing chunks, thus improving worst case allocation performance. * Fix a deadlock in base_alloc() for the error (OOM) path. * Catch integer overflow for huge allocations when using sbrk(2). * Fix bit vector initialization for run headers. This fix has no practical impact for correct programs. Incorrect programs will potentially experience allocation failures rather than memory corruption, both of which are "undefined behavior".