This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

deadlock on exit in single-thread program on libc futex with asan


Dear libc hackers,
Dear Jose,

I'm getting a funky deadlock inside libc a single-threaded program
related to gcc/ASAN (100% reproducable every time).

futex_abstimed_wait (private=0, abstime=0x0, expected=2,
futex_word=<optimized out>)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:172
172	../sysdeps/unix/sysv/linux/futex-internal.h: No such file or
directory.
(gdb) ba
#0  futex_abstimed_wait (private=0, abstime=0x0, expected=2,
futex_word=<optimized out>)
    at ../sysdeps/unix/sysv/linux/futex-internal.h:172
#1  __pthread_rwlock_wrlock_full (abstime=0x0, rwlock=0x7fbd3454e720
<__libc_setlocale_lock>)
    at pthread_rwlock_common.c:807
#2  __GI___pthread_rwlock_wrlock (rwlock=0x7fbd3454e720
<__libc_setlocale_lock>) at pthread_rwlock_wrlock.c:27
#3  0x00007fbd343c57bd in __freelocale (dataset=0x611000000040) at
freelocale.c:41
#4  0x00007fbd332a5a7f in ?? () from /usr/lib/x86_64-linux-gnu/libp11-
kit.so.0
#5  0x00007fbd35197943 in _dl_fini () at dl-fini.c:138
#6  0x00007fbd343cf720 in __run_exit_handlers (status=-1,
listp=0x7fbd3454c718 <__exit_funcs>, 
    run_list_atexit=run_list_atexit@entry=true, 
run_dtors=run_dtors@entry=true) at exit.c:108
#7  0x00007fbd343cf85a in __GI_exit (status=<optimized out>) at
exit.c:139
#8  0x00007fbd343b9bc2 in __libc_start_main (main=0x5623957f094d
<main>, argc=2, argv=0x7ffd33eef1d8, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized
out>, stack_end=0x7ffd33eef1c8)
    at ../csu/libc-start.c:342
#9  0x00005623957f025a in _start ()

This is from running 
$ taler-config -h

after building the GNU Taler *exchange* with --enable-sanitizer, but
NOT the underlying GNUnet package.

Note that taler-config is a slightly spectacular shell script:
>>
#!/usr/bin/env bash

set -eu

if ! type gnunet-config >/dev/null; then
  echo "$0 needs gnunet-config to be installed"
  exit 1
fi

# FIXME: not very portable ...
# FIXME: should use "libdir" instead of prefix/lib, but somehow
# the recursive expansion does not work ;-(.
GC=`which gnunet-config`
ASAN=""
A=`ldd $GC | grep libasan` && ASAN=`echo $A | awk '{print $3 ":"}'`
if test -z $ASAN
then
   A=`ldd @prefix@/lib/libtalerutil.so | grep libasan` && ASAN=`echo $A
| awk '{print $3 ":"}'`
fi
export LD_PRELOAD=${ASAN}${LD_PRELOAD:-}:@prefix@/lib/libtalerutil.so
exec gnunet-config "$@"
<<

Why are we doing this?

First, we preload libtalerutil to turn gnunet-config into taler-config
by having a library constructor patch some globals.

Second, as gnunet-config in this configuration is NOT using ASAN, but
libtalerutil *is* linked against ASAN. ASAN doesn't like this, and asks
to be loaded first. So we preload ASAN first as prescribed by the error
message. Naturally, as a result, the ASAN library might just be loaded
twice into the resulting binary (which I suspect might just have
something to do with the deadlock).

<irony>
Naturally, I cannot imagine why I'm the first to hit this problem ;-)
</irony>


To reproduce, you'll need the git.taler.net exchange.git, revision
6bdccb5c7bfa6728d7227e19b26f1bc9a0849fb3.


Not sure if this is libc or gcc, hence CC-ing Jose ;-).

Happy hacking!

Christian



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]