[Bug nptl/32151] New: pthread_cancel causes deadlock in syslog function

[snown at live dot cn]

https://sourceware.org/bugzilla/show_bug.cgi?id=32151

            Bug ID: 32151
           Summary: pthread_cancel causes deadlock in syslog function
           Product: glibc
           Version: 2.26
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: snown at live dot cn
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 15695
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15695&action=edit
pthread_cancel causes deadlock in syslog test demo

Descriptions:
Create two threads, A and B, each calling the syslog function, which will
probabilistically cause a deadlock in the syslog function when thread B is
cancelled by the pthread_cancel function.Test demo Please refer to the
attachment "syslog_pthreadcancel.c". Test demo gcc compilation command as
follows.
/opt/Petalinux/2018.3/tools/linux-i386/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc
-o syslog.out  syslog_pthreadcancel.c  -g -lpthread 

Reproduction Environment:
AARCH64 and AARCH32

GCC version :
root@20f5ea71ff60:~#
/opt/Petalinux/2018.3/tools/linux-i386/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc
-v
Using built-in specs.
COLLECT_GCC=/opt/Petalinux/2018.3/tools/linux-i386/aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/opt/Petalinux/2018.3/tools/linux-i386/aarch64-linux-gnu/bin/../libexec/gcc/aarch64-linux-gnu/7.3.1/lto-wrapper
Target: aarch64-linux-gnu
Configured with:
/proj/esdt_sdk/gnu_abe/ABE/builds/lin/arm/arm-linux/snapshots/gcc-linaro-7.3-2018.04-rc3/configure
SHELL=/bin/sh --with-bugurl=https://bugs.linaro.org
--with-mpc=/proj/esdt_sdk/gnu_abe/ABE/builds/lin/aarch64/aarch64-linux/builds/destdir/x86_64-unknown-linux-gnu
--with-mpfr=/proj/esdt_sdk/gnu_abe/ABE/builds/lin/aarch64/aarch64-linux/builds/destdir/x86_64-unknown-linux-gnu
--with-gmp=/proj/esdt_sdk/gnu_abe/ABE/builds/lin/aarch64/aarch64-linux/builds/destdir/x86_64-unknown-linux-gnu
--with-gnu-as --with-gnu-ld --disable-libstdcxx-pch --disable-libmudflap
--with-cloog=no --with-ppl=no --with-isl=no --disable-nls --enable-c99
--enable-gnu-indirect-function --disable-multilib --with-arch=armv8-a
--enable-fix-cortex-a53-835769 --enable-fix-cortex-a53-843419
--enable-multiarch CFLAGS=-O2 CXXFLAGS=-O2 --disable-silent-rules
--enable-libquadmath --enable-libg2c --enable-symvers=gnu
--enable-libstdcxx-pch --enable-libssp --disable-libmudflap
--enable-checking=release --enable-cheaders=c_global
--enable-poison-system-directories --enable-clocale=generic --enable-shared
--enable-threads=posix --disable-multilib --enable-c99 --without-local-prefix
--enable-lto --disable-bootstrap --with-linker-hash-style=gnu --with-ppl=no
--with-cloog=no --without-isl --enable-nls --enable-__cxa_atexit
--with-build-sysroot=/proj/esdt_sdk/gnu_abe/ABE/builds/lin/aarch64/aarch64-linux/builds/destdir/x86_64-unknown-linux-gnu/aarch64-linux-gnu/libc
--enable-plugins --enable-linker-build-id --enable-long-long --enable-shared
--with-sysroot=/proj/esdt_sdk/gnu_abe/ABE/builds/lin/aarch64/aarch64-linux/builds/destdir/x86_64-unknown-linux-gnu/aarch64-linux-gnu/libc
--enable-languages=c,c++,lto --enable-checking=yes --disable-bootstrap
--with-bugurl=https://bugs.linaro.org --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=aarch64-linux-gnu
--prefix=/proj/esdt_sdk/gnu_abe/ABE/builds/lin/aarch64/aarch64-linux/builds/destdir/x86_64-unknown-linux-gnu
Thread model: posix
gcc version 7.3.1 20180314 (Linaro GCC 7.3-2018.04-rc3)
root@20f5ea71ff60:~#

I debugged with GDB and found a deadlock inside the syslog function, the call
stack is as follows.

(gdb) thread apply all bt

Thread 2 (Thread 0xb6da7460 (LWP 749) "syslog.out"):
#0  0xb6e837e8 in __lll_lock_wait_private () from /lib/libc.so.6
#1  0xb6e728bc in __vsyslog_chk () from /lib/libc.so.6
#2  0xb6e729a4 in syslog () from /lib/libc.so.6
#3  0x000107e4 in run (arg=0x0) at syslog_pthread_cancel.c:40
#4  0xb6eecd7c in start_thread () from /lib/libpthread.so.0
#5  0xb6e763e8 in ?? () from /lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0xb6fa6010 (LWP 748) "syslog.out"):
#0  0xb6e83820 in __lll_lock_wait_private () from /lib/libc.so.6
#1  0xb6e728bc in __vsyslog_chk () from /lib/libc.so.6
#2  0xb6e729a4 in syslog () from /lib/libc.so.6
#3  0x00010abc in main () at syslog_pthread_cancel.c:103
(gdb)

I checked the syslog function source code and found that the cancel_handler
function is registered via the __libc_cleanup_push macro using __attribute__
((__cleanup__ ())) before calling __libc_lock_lock to get the lock.
Inside the cancel_handler function the __libc_lock_unlock is called to release
the lock, but I don't know why the cancel_handler function is not called after
the cancellation point.

-- 
You are receiving this mail because:
You are on the CC list for the bug.