Bug#1041836: libc6 2.36-9+deb12u1 double free abort
Hi, On 2023-08-10 16:46, Paul Szabo wrote: > I now tried the idea whether the amount of memory in the machine has a > relevance to my "inetd: double free detected in tcache 2, abort" issue. > I tried "mem=8G" and similar as kernel boot parameter; that produced > more-or-less the expected results for memory shown by "free", but did > not help to fix the issue. I may try to change physical RAM modules, > not sure whether have suitable replacements. If your issue is fully reproducible, I really doubt your issue is linked to bad memory modules. As you are able to run inetd as a separate process, I would suggest to run it under gdb to get a backtrace. Identifying the location of the double free might help to understand the issue. Alternatively as the issue seems to be different depending on the CPU, you might want to play with glibc tunables [1] to disable hardware capabilities features [2] and disable for instance AVX or SSE optimized functions. Anyway as the originally reported issue has been fixed, I am going to close the bug, however feel free to open a new one for your issue. Regards Aurelien [1] https://www.gnu.org/software/libc/manual/html_node/Tunables.html [2] https://www.gnu.org/software/libc/manual/html_node/Hardware-Capability-Tunables.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1041836: libc6 2.36-9+deb12u1 double free abort
I now tried the idea whether the amount of memory in the machine has a relevance to my "inetd: double free detected in tcache 2, abort" issue. I tried "mem=8G" and similar as kernel boot parameter; that produced more-or-less the expected results for memory shown by "free", but did not help to fix the issue. I may try to change physical RAM modules, not sure whether have suitable replacements. Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia
Bug#1041836: libc6 2.36-9+deb12u1 double free abort
Dear Aurelien, I used LD_PRELOAD=libc_malloc_debug.so for MALLOC_CHECK_. With those extra checks (tried all values of MALLOC_CHECK_ from 0 to 20), glibc did not show any errors, suggesting that the bug is not in inetd. The original poster said his issue shows on some hardware only. I observed my issue on a wider range of CPUs: present on Xeon4309Y, Xeon6326 and i7-8700, but not on i7-4790, i5-4570, i5-3470, N5105 or x5-Z8350. Maybe the difference is in the RAM of the machine? Those with my issue have 16GB or more, those without have 8GB or less. Cheers, Paul
Bug#1041836: libc6 2.36-9+deb12u1 double free abort
Hi, What you reported seems unrelated to the original issue. It's better to open a new bug if you believe there is in issue in glibc. On 2023-08-09 10:46, Paul Szabo wrote: > Maybe related: seems that the default for "mcheck" or MALLOC_CHECK_ has > changed. > > I observe an oddity. I only noticed this recently, with libc6 version > 2.36-9+deb12u1; reverting to previous 2.36-9 did not seem to help. > > The issue. Sending SIGHUP to the inetd(8) process should cause it to > re-load its configuration, but instead it elicits > > free(): double free detected in tcache 2 > > and an abort. This is easiest seen (after "systemctl stop inetd") with > > root# inetd -d -i & sleep 1; kill -HUP $!; sleep 1; jobs > [1] 2431 > ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 > server=/usr/sbin/identd > free(): double free detected in tcache 2 > [1]+ Aborted inetd -d -i > root# This is very likely a bug in inetd. There is no default value in MALLOC_CHECK_, by default a fast memory allocator which is not tolerant against simple errors is used, and thus just aborts in that case. > Sanity(?) is restored by using MALLOC_CHECK_=0 (needs LD_PRELOAD): > > root# LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 inetd -d -i & sleep > 1; kill -HUP $!; sleep 1; jobs; kill $!; sleep 1; jobs > [1] 2437 > ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 > server=/usr/sbin/identd > REDO: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) > builtin=0 server=/usr/sbin/identd > [1]+ Running LD_PRELOAD=libc_malloc_debug.so > MALLOC_CHECK_=0 inetd -d -i & > [1]+ DoneLD_PRELOAD=libc_malloc_debug.so > MALLOC_CHECK_=0 inetd -d -i > root# > > To compound the oddity, the value of MALLOC_CHECK_ or even its presence > seems ignored, just the LD_PRELOAD=libc_malloc_debug.so "fixes" the > issue. Since glibc 2.34, the debugging features in malloc such as the MALLOC_CHECK_ environment variable are not built-in anymore and require to preload the libc_malloc_debug.so library. This allows one to change the level of checks through the MALLOC_CHECK_ environment variable. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1041836: libc6 2.36-9+deb12u1 double free abort
Maybe related: seems that the default for "mcheck" or MALLOC_CHECK_ has changed. I observe an oddity. I only noticed this recently, with libc6 version 2.36-9+deb12u1; reverting to previous 2.36-9 did not seem to help. The issue. Sending SIGHUP to the inetd(8) process should cause it to re-load its configuration, but instead it elicits free(): double free detected in tcache 2 and an abort. This is easiest seen (after "systemctl stop inetd") with root# inetd -d -i & sleep 1; kill -HUP $!; sleep 1; jobs [1] 2431 ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 server=/usr/sbin/identd free(): double free detected in tcache 2 [1]+ Aborted inetd -d -i root# Sanity(?) is restored by using MALLOC_CHECK_=0 (needs LD_PRELOAD): root# LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 inetd -d -i & sleep 1; kill -HUP $!; sleep 1; jobs; kill $!; sleep 1; jobs [1] 2437 ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 server=/usr/sbin/identd REDO: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 server=/usr/sbin/identd [1]+ Running LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 inetd -d -i & [1]+ DoneLD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 inetd -d -i root# To compound the oddity, the value of MALLOC_CHECK_ or even its presence seems ignored, just the LD_PRELOAD=libc_malloc_debug.so "fixes" the issue. Hope this helps to find the cause. Cheers, Paul References: http://btorpey.github.io/blog/2019/07/14/memory-checking/ https://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
