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 (I assume), but not the _libc function.
Whoops. One option would be to change glibc to not call free and call something direct. Or perhaps to call memalign() instead of __libc_memalign. This is in dl-tls.c, and I'm inclined to not muck with things.
Likely, I'll just prevent all code from linking with efence until we can get a better fix. Possibly some sort of 'efence disable' call, though that might be a pain - esp with concurrent ops.
Here's a BT for those curious. Though it is a little weird that it thinks that pthread_free_stack() called uthread_free_tls(). Might be BT noise.
``
01 Addr 0x000000000040c854 is in signal at offset 0x000000000000c854 fatal_backtrace /usr/local/google/home/brho/akaros/ros-kernel/user/parlib/panic.c:25
02 Addr 0x0000000000405edb is in signal at offset 0x0000000000005edb EF_Abort /usr/local/google/home/brho/akaros/ros-kernel/user/electric-fence/print.c:119
03 Addr 0x0000000000405255 is in signal at offset 0x0000000000005255 free /usr/local/google/home/brho/akaros/ros-kernel/user/electric-fence/efence.c:675
04 Addr 0x000000000040a6f4 is in signal at offset 0x000000000000a6f4 __uthread_free_tls /usr/local/google/home/brho/akaros/ros-kernel/user/parlib/uthread.c:1236
05 Addr 0x0000000000403f33 is in signal at offset 0x0000000000003f33 __pthread_free_stack /usr/local/google/home/brho/akaros/ros-kernel/user/pthread/pthread.c:445
06 Addr 0x00000000004026c6 is in signal at offset 0x00000000000026c6 __uthread_yield /usr/local/google/home/brho/akaros/ros-kernel/user/parlib/uthread.c:416
07 Addr 0x000000000040b3b5 is in signal at offset 0x000000000000b3b5 uthread_yield /usr/local/google/home/brho/akaros/ros-kernel/user/parlib/uthread.c:496
08 Addr 0x000000000040b815 is in signal at offset 0x000000000000b815 uth_2ls_thread_exit /usr/local/google/home/brho/akaros/ros-kernel/user/parlib/uthread.c:1336
09 Addr 0x0000000000404a5e is in signal at offset 0x0000000000004a5e pthread_exit_no_cleanup /usr/local/google/home/brho/akaros/ros-kernel/user/pthread/pthread.c:726
10 Addr 0x0000000000404a80 is in signal at offset 0x0000000000004a80 pthread_exit /usr/local/google/home/brho/akaros/ros-kernel/user/pthread/pthread.c:730
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 (I assume), but not the _libc function.
Whoops. One option would be to change glibc to not call free and call something direct. Or perhaps to call memalign() instead of __libc_memalign. This is in dl-tls.c, and I'm inclined to not muck with things.
Likely, I'll just prevent all code from linking with efence until we can get a better fix. Possibly some sort of 'efence disable' call, though that might be a pain - esp with concurrent ops.
Here's a BT for those curious. Though it is a little weird that it thinks that pthread_free_stack() called uthread_free_tls(). Might be BT noise.
``
01 Addr 0x000000000040c854 is in signal at offset 0x000000000000c854 fatal_backtrace /usr/local/google/home/brho/akaros/ros-kernel/user/parlib/panic.c:25
02 Addr 0x0000000000405edb is in signal at offset 0x0000000000005edb EF_Abort /usr/local/google/home/brho/akaros/ros-kernel/user/electric-fence/print.c:119
03 Addr 0x0000000000405255 is in signal at offset 0x0000000000005255 free /usr/local/google/home/brho/akaros/ros-kernel/user/electric-fence/efence.c:675
04 Addr 0x000000000040a6f4 is in signal at offset 0x000000000000a6f4 __uthread_free_tls /usr/local/google/home/brho/akaros/ros-kernel/user/parlib/uthread.c:1236
05 Addr 0x0000000000403f33 is in signal at offset 0x0000000000003f33 __pthread_free_stack /usr/local/google/home/brho/akaros/ros-kernel/user/pthread/pthread.c:445
06 Addr 0x00000000004026c6 is in signal at offset 0x00000000000026c6 __uthread_yield /usr/local/google/home/brho/akaros/ros-kernel/user/parlib/uthread.c:416
07 Addr 0x000000000040b3b5 is in signal at offset 0x000000000000b3b5 uthread_yield /usr/local/google/home/brho/akaros/ros-kernel/user/parlib/uthread.c:496
08 Addr 0x000000000040b815 is in signal at offset 0x000000000000b815 uth_2ls_thread_exit /usr/local/google/home/brho/akaros/ros-kernel/user/parlib/uthread.c:1336
09 Addr 0x0000000000404a5e is in signal at offset 0x0000000000004a5e pthread_exit_no_cleanup /usr/local/google/home/brho/akaros/ros-kernel/user/pthread/pthread.c:726
10 Addr 0x0000000000404a80 is in signal at offset 0x0000000000004a80 pthread_exit /usr/local/google/home/brho/akaros/ros-kernel/user/pthread/pthread.c:730
``