glibc 2.34 implements close_range(2), which is used by the ssh client
(amongst others). This needs to be overridden to make sure ssh does not
close lttng-ust file descriptors.
`len_type' of a sequence field must be of type unsigned integer. Some
provided examples in the man page were incorrectly using a type signed
integer, resulting in correct compilation, but error while decoding.
Fix: libc wrapper: use initial-exec for malloc_nesting TLS
Use the initial-exec TLS model for the malloc_nesting nesting guard
variable to ensure that the glibc implementation of the TLS access don't
trigger infinite recursion by calling the memory allocator wrapper
functions, which can happen with global-dynamic.
Considering that the libc wrapper is meant to be loaded with LD_PRELOAD
anyway (never with dlopen(3)), we always expect the libc to have enough
space to hold the malloc_nesting variable.
In addition to change the malloc_nesting from global-dynamic to
initial-exec, this removes the URCU TLS compatibility layer from the
libc wrapper, which is a good thing: this compatibility layer relies
on pthread key and calloc internally, which makes it a bad fit for TLS
accesses guarding access to malloc wrappers, due to possible infinite
recursion.
a299ee8...
by
Michael Jeanson <email address hidden>
fix: clean java inner class files in examples
Java classes that contain inner classes will result in additional class
files being created when compiled in the form of
'Class$InnerClass.class'. Expand the clean target to delete those
additional files.
Clang is strict about the volatile qualifier on function pointers. It
also wants pointers to be passed to atomic builtins, even for
functions. Therefore, use the addresses of function pointers even if
unnecessary according to C standard.
Assuming that `dlsym(RTLD_NEXT, "symbol")' is invariant for "symbol",
then we could think that memory operations on the `plibc_func' pointers can
be safely done without atomics.
However, consider what would happen if a load to a`plibc_func' pointer
is torn apart by the compiler. Then a thread could see:
1) NULL
2) The stored value as returned by a dlsym() call
3) A mix of 1) and 2)
The same goes for other optimizations that a compiler is authorized to
do (e.g. store tearing, load fusing).
One could question whether such race condition is even possible for the
clone(2) wrapper. Indeed, a thread must be cloned to get into
existence. Therefore, the main thread would always store the value of
`plibc_func' at least once before creating the first sibling thread,
preventing any possible race condition for this wrapper. However, this
assume that the main thread will not call the clone system call directly
before calling the libc wrapper! Thus, to be on the safe side, we do the
same for the clone wrapper.
Fix the race conditions by using the uatomic_read/uatomic_set functions,
on access to `plibc_func' pointers.
