Building with gcc-12, -fsanitize=undefined, -O1 on x86_64 ubuntu linux, results in the glibc malloc/free base library complaining at runtime about a double free. This issue is not seen when compiling -O0 and -Og, but is seen -O1, -O2, -O3. I have not run asan to provide more powerful analysis. I do not know if this happens on ARM64 hosts. I do not know if this represents a bug in the ubsan instrumentation, a bug in gcc-12 optimization, or a bug in the dotnet/runtime.
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140735140050496) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=140735140050496) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=140735140050496, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff7445476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007ffff742b7f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007ffff748c6f6 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff75deb8c "%s\n")
at ../sysdeps/posix/libc_fatal.c:155
#6 0x00007ffff74a3d7c in malloc_printerr (str=str@entry=0x7ffff75e17b0 "double free or corruption (out)") at ./malloc/malloc.c:5664
#7 0x00007ffff74a5ef0 in _int_free (av=0x7ffff761cc80 <main_arena>, p=0x7fff6c003bc0, have_lock=<optimized out>) at ./malloc/malloc.c:4588
#8 0x00007ffff74a84d3 in __GI___libc_free (mem=<optimized out>) at ./malloc/malloc.c:3391
#9 0x00007ffff61eeaa2 in PAL_free (pvMem=<optimized out>)
at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/pal/src/cruntime/malloc.cpp:79
#10 0x00007ffff60c38b6 in ClrFree (p=<optimized out>)
at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/utilcode/clrhost_nodependencies.cpp:304
#11 operator delete[] (p=<optimized out>) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/utilcode/clrhost_nodependencies.cpp:410
#12 0x00007ffff5bcdda9 in StackingAllocator::~StackingAllocator (this=this@entry=0x7fff6c001470, __in_chrg=<optimized out>)
at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/vm/stackingallocator.cpp:76
#13 0x00007ffff5a1d6b7 in Delete<StackingAllocator> (value=0x7fff6c001470)
at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/inc/holder.h:999
#14 FunctionBase<StackingAllocator*, &(void DoNothing<StackingAllocator*>(StackingAllocator*)), &(void Delete<StackingAllocator>(StackingAllocator*))>::DoRelease (this=0x7fff74079370) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/inc/holder.h:716
#15 BaseHolder<StackingAllocator*, FunctionBase<StackingAllocator*, &(void DoNothing<StackingAllocator*>(StackingAllocator*)), &(void Delete<StackingAllocator>(StackingAllocator*))>, 0ul, &(int CompareDefault<StackingAllocator*>(StackingAllocator*, StackingAllocator*))>::Release
(this=0x7fff74079370) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/inc/holder.h:293
#16 BaseHolder<StackingAllocator*, FunctionBase<StackingAllocator*, &(void DoNothing<StackingAllocator*>(StackingAllocator*)), &(void Delete<StackingAllocator>(StackingAllocator*))>, 0ul, &(int CompareDefault<StackingAllocator*>(StackingAllocator*, StackingAllocator*))>::~BaseHolder (this=0x7fff74079370, __in_chrg=<optimized out>) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/inc/holder.h:261
#17 BaseWrapper<StackingAllocator*, FunctionBase<StackingAllocator*, &(void DoNothing<StackingAllocator*>(StackingAllocator*)), &(void Delete<StackingAllocator>(StackingAllocator*))>, 0ul, &(int CompareDefault<StackingAllocator*>(StackingAllocator*, StackingAllocator*))>::~BaseWrapper (this=0x7fff74079370, __in_chrg=<optimized out>) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/inc/holder.h:469
#18 Wrapper<StackingAllocator*, &(void DoNothing<StackingAllocator*>(StackingAllocator*)), &(void Delete<StackingAllocator>(StackingAllocator*)), 0ul, &(int CompareDefault<StackingAllocator*>(StackingAllocator*, StackingAllocator*)), true>::~Wrapper (this=0x7fff74079370,
__in_chrg=<optimized out>) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/inc/holder.h:781
#19 SpecializedWrapper<StackingAllocator, &(void Delete<StackingAllocator>(StackingAllocator*))>::~SpecializedWrapper (
this=0x7fff74079370, __in_chrg=<optimized out>) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/inc/holder.h:846
#20 ClassLoader::CreateTypeHandleForTypeDefThrowing (pModule=<optimized out>, cl=<optimized out>, inst=...,
pamTracker=pamTracker@entry=0x7fff74079680) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/vm/methodtablebuilder.cpp:12431
#21 0x00007ffff55f4178 in ClassLoader::CreateTypeHandleForTypeKey (pKey=pKey@entry=0x7fff74079ab0,
pamTracker=pamTracker@entry=0x7fff74079680) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/vm/typekey.h:146
#22 0x00007ffff55f5593 in ClassLoader::DoIncrementalLoad (pTypeKey=pTypeKey@entry=0x7fff74079ab0, typeHnd=...,
currentLevel=currentLevel@entry=CLASS_LOAD_BEGIN) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/vm/clsload.cpp:2883
#23 0x00007ffff55f6d5e in ClassLoader::LoadTypeHandleForTypeKey_Body (this=this@entry=0x555555690730,
pTypeKey=pTypeKey@entry=0x7fff74079ab0, typeHnd=..., targetLevel=targetLevel@entry=CLASS_LOAD_EXACTPARENTS)
at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/vm/clsload.cpp:3559
#24 0x00007ffff55f79bd in ClassLoader::LoadTypeHandleForTypeKey (this=this@entry=0x555555690730, pTypeKey=pTypeKey@entry=0x7fff74079ab0,
--Type <RET> for more, q to quit, c to continue without paging--q
Quit
(gdb) frame 12
#12 0x00007ffff5bcdda9 in StackingAllocator::~StackingAllocator (this=this@entry=0x7fff6c001470, __in_chrg=<optimized out>)
at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/vm/stackingallocator.cpp:76
76 delete [] (char*)m_DeferredFreeBlock;
Description
Building with gcc-12, -fsanitize=undefined, -O1 on x86_64 ubuntu linux, results in the glibc malloc/free base library complaining at runtime about a double free. This issue is not seen when compiling -O0 and -Og, but is seen -O1, -O2, -O3. I have not run asan to provide more powerful analysis. I do not know if this happens on ARM64 hosts. I do not know if this represents a bug in the ubsan instrumentation, a bug in gcc-12 optimization, or a bug in the dotnet/runtime.
Reproduction Steps
see above
Expected behavior
no runtime error from glibc free complaining about double free
Actual behavior
runtime error
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
/cc @AaronRobinsonMSFT