On Tue, 26 Mar 2024, Peter Fraser wrote: > Ls fault with symbols > > lldb /usr/src/bin/ls/ls > (lldb) target create "/usr/src/bin/ls/ls" > Current executable set to '/usr/src/bin/ls/ls' (x86_64). > (lldb) run -l > run -l > Process 88451 launched: '/usr/src/bin/ls/ls' (x86_64) > total 2176 > c--------x 1 34078976 wheel 58, 7079544 Dec 31 1969 #04963796 > Process 88451 stopped > * thread #1, stop reason = signal SIGSEGV > frame #0: 0x000008ea7a956fc8 libc.so.97.1`_fmt(format=<unavailable>, > t=0x0000000000000000, pt="Dec 31 1969" > , ptlim="", warnp=0x000074ad2bf8ceb4) at strftime.c:159:19 > (lldb) bt > bt > * thread #1, stop reason = signal SIGSEGV > * frame #0: 0x000008ea7a956fc8 libc.so.97.1`_fmt(format=<unavailable>, > t=0x0000000000000000, pt="Dec 31 1969" > , ptlim="", warnp=0x000074ad2bf8ceb4) at strftime.c:159:19 > frame #1: 0x000008ea7a9569ea libc.so.97.1`_libc_strftime(s="Dec 31 > 1969", maxsize=64, format=<unavailable>, > t=<unavailable>) at strftime.c:118:6
Okay, that explains it: the (presumably corrupted) stat information returned for the second directory entry to display has a timestamp that is not representable in a struct tm, so localtime() returned NULL and strftime() then crashed trying to dereference through NULL. Someone want to craft a diff for ls to handle that (and scan the tree for other unchecked localtime(<uncontrolled data>) calls)? Not sure if POSIX's ls spec has an out for how to print the time for such a thing. Meanwhile: unless you were testing excessively large positive or negative time_t values for files, we can presume there are inodes with bogus data and the filesystem is not trustable at this point. Time to reformat, IMHO. Philip
