tree 37658ec86ab7628e7c02e24522767a4b408da504
parent a6f5d77deac91a8d5544c05bd379ab207f1b7578
author Barret Rhoden <brho@cs.berkeley.edu> 1531252298 -0400
committer Barret Rhoden <brho@cs.berkeley.edu> 1531252298 -0400

Don't use the electric fence in multithreaded code

The efence doesn't work with uthreads.  Efence intercepts malloc() et al.
When a uthread exits, its TLS is cleaned up.  Ultimately, this calls into
glibc, which calls free() on the TLS region in _dl_deallocate_tls(). That
region was allocated with __libc_memalign() in _dl_allocate_tls_storage().
efence can intercept the free(), but not the _libc function.

Pending other changes, we shouldn't use uthreads and the efence.  One
option would be to briefly disable the efence.  Another would be to not
actually free the TLS if the efence is linked in.  Neither are good
options.

For now, we'd like to not crash our utests.  The only code using it was
utests - some of which would break in a somewhat racy manner.

You can still link in the efence on demand.  If you do, I'd hack up your
2LS to have threads sleep forever when they finish (pthread.c, look for the
start_routine).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>