Bug#1041836: libc6 2.36-9+deb12u1 double free abort

2023-08-10 Thread Aurelien Jarno
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

Bug#1041836: libc6 2.36-9+deb12u1 double free abort

2023-08-10 Thread Paul Szabo
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

Bug#1041836: libc6 2.36-9+deb12u1 double free abort

2023-08-09 Thread Paul Szabo
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

Bug#1041836: libc6 2.36-9+deb12u1 double free abort

2023-08-09 Thread Aurelien Jarno
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

Bug#1041836: libc6 2.36-9+deb12u1 double free abort

2023-08-08 Thread Paul Szabo
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