On Wed, Feb 02, 2022 at 06:45:34PM -0500, Sean Caron wrote: > Sure! Please see gdb backtrace output below. > > (gdb) bt > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 > #1 0x00007f289d5c7921 in __GI_abort () at abort.c:79 > #2 0x00007f289d610967 in __libc_message (action=action@entry=do_abort, > fmt=fmt@entry=0x7f289d73db0d "%s\n") at ../sysdeps/posix/libc_fatal.c:181 > #3 0x00007f289d6179da in malloc_printerr ( > str=str@entry=0x7f289d73f368 "malloc_consolidate(): invalid chunk > size") at malloc.c:5342 > #4 0x00007f289d617c7e in malloc_consolidate > (av=av@entry=0x7f289d972c40 <main_arena>) > at malloc.c:4471 > #5 0x00007f289d61b968 in _int_malloc (av=av@entry=0x7f289d972c40 <main_arena>, > bytes=bytes@entry=33328) at malloc.c:3713 > #6 0x00007f289d620275 in _int_memalign (bytes=32768, alignment=512, > av=0x7f289d972c40 <main_arena>) > at malloc.c:4683 Ok, so there's nothing wrong with the memalign() parameters being passed to glibc, so something has previously caused heap corruption that is only now being tripped over trying to allocate memory for a new inode cluster buffer. I wonder if it was the zeroing of the "unused" part of the inode data fork area that did this (perhaps a corrupt inode fork offset?) so maybe it is worth turning off the stale data zeroing function (-a to copy all metadata blocks) so that it doesn't try to interpret corrupt metadata to determine what is unused areas or not... If that does get past this inode, then we'll need to make the stale region zeroing a lot more careful and avoid zeroing in the case of badly broken metadata. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
