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>
diff --git a/user/utest/Makefile b/user/utest/Makefile index eb50640..17089ea 100644 --- a/user/utest/Makefile +++ b/user/utest/Makefile
@@ -10,7 +10,7 @@ OBJDIR := $(SRCDIR)obj INCDIR = $(SRCDIR)include -LDLIBS := -lpthread -lbenchutil -lm -liplib -lndblib -lelectric-fence +LDLIBS := -lpthread -lbenchutil -lm -liplib -lndblib uc = $(shell echo $(1) | tr a-z A-Z)