ls is statically linked, could you build from src with "make DEBUG=-g" and obtain a fresh backtrace?
On 2024/03/26 17:59, Peter Fraser wrote: > I never expected it was the number files, I give the number to show that it > was some what of general error that populated lost+found > > Using lldb > > (lldb) run -l > run -l > Process 89184 launched: '/bin/ls' (x86_64) > total 2176 > c--------x 1 34078976 wheel 58, 7079544 Dec 31 1969 #04963796 > Process 89184 stopped > * thread #1, stop reason = signal SIGSEGV > frame #0: 0x00000ae35b5aef18 ls`___lldb_unnamed_symbol508 + 1432 > ls`___lldb_unnamed_symbol508: > -> 0xae35b5aef18 <+1432>: movl 0x10(%r11), %ecx > 0xae35b5aef1c <+1436>: leaq -0x42c8b(%rip), %rax > 0xae35b5aef23 <+1443>: cmpq $0xb, %rcx > 0xae35b5aef27 <+1447>: ja 0xae35b5aef34 ; <+1460> > Process 89184 stopped > * thread #1: tid = 185603, 0x00000ae35b5aef18 ls`___lldb_unnamed_symbol508 + > 1432, stop reason = signal SIGSEGV > (lldb) thread backtrace > thread backtrace > * thread #1, stop reason = signal SIGSEGV > * frame #0: 0x00000ae35b5aef18 ls`___lldb_unnamed_symbol508 + 1432 > frame #1: 0x00000ae35b5ae93a ls`___lldb_unnamed_symbol507 + 90 > frame #2: 0x00000ae35b578111 ls`___lldb_unnamed_symbol26 + 993 > frame #3: 0x00000ae35b577ac9 ls`___lldb_unnamed_symbol22 + 1353 > frame #4: 0x00000ae35b57745f ls`___lldb_unnamed_symbol20 + 495 > frame #5: 0x00000ae35b57721f ls`___lldb_unnamed_symbol19 + 1887 > frame #6: 0x00000ae35b5764c2 ls`___lldb_unnamed_symbol5 + 338 > (lldb) > > -----Original Message----- > From: Omar Polo <o...@omarpolo.com> > Sent: Tuesday, March 26, 2024 1:37 PM > To: Peter Fraser <p...@thinkage.ca> > Cc: bugs@openbsd.org > Subject: Re: ls -l Segmentation fault > > [moving to bugs@] > > On 2024/03/26 17:15:28 +0000, Peter Fraser <p...@thinkage.ca> wrote: > > For some reason I don't know my partition /var/www got screwed up and there > > was a long list in /var/www/lost+found. > > > > Since I populate /var/www by using rsync from another computer, and I > > expect didn't notice the existence of lost+found for a long time. > > > > "ls" on the directory works but "ls -l" faults with > > > > ls -l > > total 2176 > > c--------x 1 34078976 wheel 58, 7079544 Dec 31 1969 #04963796 > > Segmentation fault (core dumped) > > > > The directory has 1324 files in it. > > > > I have included the core dump of "ls" > > > > If you try to tar the files in the directory, you get very strange message, > > but the files are ignored and the is not faults. > > I still have them if anyone wants to examine them. If not, I will try to > > delete them. > > the corefile alone is not going to be of much help due to the random libc > relinking; can you show the backtrace? lldb in base should work, otherwise > use egdb from the gdb package. > > $ ls -l > [assuming it crashes] > $ egdb ls ls.core > [useless copyright stuff elided] > (gdb) bt > > and paste the output in a mail. re-compiling ls with debug symbols (cd > /usr/src/bin/ls && make DEBUG='-g' && doas make DEBUG='-g' install) could be > useful too. > > For what is worth, I have a maildir with 14k files and haven't noticed > crashes, so the number of entries it's probably not the culprit. > > > Thanks, >
