[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[francis.deslauriers at efficios dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589

francis.deslauriers at efficios dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |francis.deslauriers@efficio
                   |                            |s.com

--- Comment #12 from francis.deslauriers at efficios dot com ---
I am witnessing the exact same issue on Ubuntu 20.04.2.

I see the same symptoms with ps, pgrep, w, w.procps, uptime, vmstat, top, and
free. It seems that most of the tools of the procps project have this issue.

I see the same callstack that mccannd@ shared.

I could find one reference to this issue[1].

[1]
https://unix.stackexchange.com/questions/652288/why-pgrep-hangs-when-clang-addresssanitizer-library-is-preloaded-using-ld-preloa

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[mathieu.desnoyers at efficios dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589

Mathieu Desnoyers <mathieu.desnoyers at efficios dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mathieu.desnoyers@efficios.
                   |                            |com

--- Comment #13 from Mathieu Desnoyers <mathieu.desnoyers at efficios dot com> ---
So I reproduced this hang with pgrep on my Ubuntu 18.04.1 LTS.

LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/{8,9,10,11}/libasan.so pgrep something
[ hang ]

but 

LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/7/libasan.so pgrep something [ does
not hang ]

So I focus my investigation on gcc 8's libasan which is the first to introduce
this issue.

The version of glibc on this x86-64 machine is 2.27-3ubuntu1.4.

I added breakpoints on all rwlock read lock, write lock, and unlock operations
(__GI___pthread_rwlock_rdlock, __GI___pthread_rwlock_wrlock,
__GI___pthread_rwlock_unlock). Looking at what happens to the _nl_state_lock
which protects glibc's i18n handling data structures is quite enlightening.
This lock is _not_ a recursive lock. AFAIU what happens here is that:

1. intl/bindtextdom.c:set_binding_values() locks the _nl_state_lock write lock.
2. it calls malloc, but this symbol is overridden by libasan.
3. asan's malloc handler ReplaceSystemMalloc looks up "__libc_malloc_dispatch"
and if that fails it looks up "__libc_malloc_default_dispatch".
4. The dlsym lookup failure calls __dlerror, which performs a i18n lookup, thus
taking the _nl_state_lock read lock. This should not happen, as it is not a
nestable lock.
5. The _nl_state_lock is unlocked once after the i18n lookup is done.
6. The _nl_state lock is unlocked again in set_binding_values(), which corrupts
the lock state because it is not a nestable lock.
7. The next unlucky caller trying to take the lock hangs forever on futex.

Based on an IRC discussion with Carlos O'Donell, it appears to be a defect in
glibc that a malloc interposer fails during i18n translation. There was a
discussion back in 2014
(https://sourceware.org/legacy-ml/libc-alpha/2014-12/msg00954.html) regarding
reentrancy of dlopen and other libdl interfaces.

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[mathieu.desnoyers at efficios dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589

--- Comment #14 from Mathieu Desnoyers <mathieu.desnoyers at efficios dot com> ---
I've proposed a RFC patch on the libc-alpha mailing list which fixes the issue:
https://sourceware.org/pipermail/libc-alpha/2021-August/130129.html

It does have a few downsides: it turns all i18n rwlocks into nestable mutexes,
which may be slower when there are many concurrent readers. I've also changed
all i18n locks to a nestable scheme, so maybe we can be more specific.

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Mathieu Desnoyers from comment #14)
> I've proposed a RFC patch on the libc-alpha mailing list which fixes the
> issue: https://sourceware.org/pipermail/libc-alpha/2021-August/130129.html
> 
> It does have a few downsides: it turns all i18n rwlocks into nestable
> mutexes, which may be slower when there are many concurrent readers. I've
> also changed all i18n locks to a nestable scheme, so maybe we can be more
> specific.

Maybe it is best if you file a glibc bug too.

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[mathieu.desnoyers at efficios dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589

--- Comment #16 from Mathieu Desnoyers <mathieu.desnoyers at efficios dot com> ---
(In reply to Andrew Pinski from comment #15)

> Maybe it is best if you file a glibc bug too.

There was already a glibc bug reporting this. I've done the required changes to
reopen it.

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |MOVED

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Move to the over to the glibc bug.

[Bug sanitizer/90589] In Fedora 30 ps hangs using address sanitizer

[mathieu.desnoyers at efficios dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90589

--- Comment #18 from Mathieu Desnoyers <mathieu.desnoyers at efficios dot com> ---
Created attachment 51302
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51302&action=edit
Interceptor library working-around glibc's intl issues for malloc interceptors