[Bug libgcc/96332] New: Asan (libasan) deadlock inside a malloc

2020-07-27 Thread raster at rasterman dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96332

Bug ID: 96332
   Summary: Asan (libasan) deadlock inside a malloc
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raster at rasterman dot com
  Target Milestone: ---

I noticed this in 10.0.0 as well, just updated to 10.1 and still there.
Specific version + build info:

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (GCC)

This happens every time for me when I use asan to build efl + enlightenment
(http://www.enlightenment.org). Asan used to work fine in gcc 9. I get a
deadlock inside libasan inside opendir inside an malloc:

#0 
__sanitizer::atomic_exchange<__sanitizer::atomic_uint32_t>(__sanitizer::atomic_uint32_t
volatile*, __sanitizer::atomic_uint32_t::Type, __sanitizer::memory_order)
(mo=__sanitizer::memory_order_acquire, v=2, a=0x640021c0)
at
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:62
#1  __sanitizer::BlockingMutex::Lock() (this=this@entry=0x640021c0)
at /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_linux.cpp:652
#2  0x7fddad443d68 in
__sanitizer::GenericScopedLock<__sanitizer::BlockingMutex>::GenericScopedLock(__sanitizer::BlockingMutex*)
(mu=0x640021c0, this=)
at /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_mutex.h:181
#3 
__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>::GetFromAllocator(__sanitizer::AllocatorStats*, unsigned long, unsigned int*,
unsigned long) (this=0x7fddad54a9c0 <__asan::instance>,
this@entry=0x7fdda894c7b0, stat=stat@entry=0x7fdda894ec40,
class_id=class_id@entry=45, chunks=chunks@entry=0x7fdda894c7c0,
n_chunks=n_chunks@entry=1)
at
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:142
#4  0x7fddad443e85 in
__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>
>::Refill(__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__saniti--Type
 for more, q to--Type  for more, q to---Type  for more, q to
quit, c to continue without paging--
ned long) (this=this@entry=0x7fdda89410e0, c=c@entry=0x7fdda894c7b0,
allocator=allocator@entry=0x7fdda894c7b0, class_id=class_id@entry=45) at
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_allocator_local_cache.h:86
#5  0x7fddad444179 in
__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>
>::Allocate(__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>*, unsigned long)
(class_id=45, allocator=0x7fdda894c7b0, this=0x7fdda89410e0) at
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_allocator_local_cache.h:33
#6 
__sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
>,
__sanitizer::LargeMmapAllocatorPtrArrayDynamic>::Allocate(__sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSpaceView>
> >*, unsigned long, unsigned long) (this=this@entry=0x7fddad54a9c0
<__asan::instance>, cache=cache@entry=0x7fdda89410e0, size=,
size@entry=33840, alignment=alignment@entry=8) at
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_allocator_combined.h:69
#7  0x7fddad44435a in __asan::Allocator::Allocate(unsigned long, unsigned
long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool)
(this=this@entry=0x7fddad54a9c0 <__asan::instance>, size=size@entry=32816,
alignment=alignment@entry=8, stack=stack@entry=0x7ffef49ca810,
alloc_type=alloc_type@entry=__asan::FROM_MALLOC, can_fill=can_fill@entry=true)
at /build/gcc/src/gcc/libsan

[Bug libgcc/96332] Asan (libasan) deadlock inside a malloc

2020-07-27 Thread raster at rasterman dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96332

--- Comment #2 from Carsten Haitzler  ---
oh sorry - my bad. i didn't realize i had pasted it twice. a single bt - only a
single thread at the time (info threads in gdb reports just one).

[Bug sanitizer/96332] Asan (libasan) deadlock inside a malloc

2020-09-07 Thread raster at rasterman dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96332

--- Comment #3 from Carsten Haitzler  ---
Anyone able to reproduce?