ls -l segfault + [PATCH]

[Denis Vlasenko]

On Friday 16 March 2007 20:38, Harald Küthe wrote:
> >>  It seems that show_files is at line 430 and list_single is inlined.
> >>
> >>  I also tried with valgrind. No problems reported. And it does not 
> >> segfault, either.
> >>
> >>  I also made a binary that is compiled with -O0 (no optimization). It 
> >> failed myteriously thus:
> >>  (gdb) bt full
> >> #0  0x0805891a in openvt_main (argc=804208, argv=0xb7f95ae0) at 
> >> console-tools/openvt.c:35
> >>          fd = 0
> >>          vtname = "\b\001\000\000\000ÿ\000\000\000¡\000\000"
> >>  #1  0x00000000 in ?? ()
> >> This binary also works succesfully with valgrind. And without -l.
>
> >I propose the following:
> >1) try latest svn
> >2) add debug printouts to ls.c [using write, not printf!
> >   printf can make such 'volatile' bugs disappear]:
> > write(2, "HERE\n", 5);
> >   by adding them here and there, rerunning ls, you
> > will fairly quickly narrow it down.
> >3) show results to the list
> 
> I have the same problem here and I narrowed it down to some point:
> It seems that the buffer bb_common_bufsiz1 will be overwritten
> if there are many files to be listed with <ls -l>.
> 
> Here it failes in list_single(struct dnode *dn)
> when dn is wrong (looks like some previous ls printout is at dn, so it 
> crashes)
> When I increase BUFSIZ there is no crash.
> 
> My preferred change is to use line buffered stdout handling instead of block 
> buffered:
> bb/coreutils/ls.c line 795:
> -     setvbuf(stdout, bb_common_bufsiz1, _IOFBF, BUFSIZ);
> +     setvbuf(stdout, bb_common_bufsiz1, _IOLBF, BUFSIZ);
> I don't know why this doesn't happen with ls or ls -la.
> It seems strace changes the way stdout is handled so it doesn't crash there 
> (and it does not crash in gdb :-()
>
> my Env:
> ppc8xx
> linux-2.4.34
> glibc-2.3.6
> gcc-3.4.4
> enabled 64bit stuff: _FILE_OFFSET_BITS=64
> bb 1.4.1

Wow.

Just tested - it doesn't crash here on x86-64 with glibc-2.4. In strace I see
perfectly normal BUFSIZ-sized writes:
write(1, "---x------    1 root     root   "..., 8192) = 8192

When you strace faulty bbox ls, do you see writes _larger_ than BUFSIZ
before it crash?

Does it crash if you stop using bb_common_bufsiz1 and let glibc allocate its
own buffer with  setvbuf(stdout, NULL, _IOFBF, BUFSIZ)?

Changing to line buffering is not a real solution - other applets will
still be prone to the same problem.

I doubt that it is a kernel or gcc problem, it's either glibc-2.3.6 problem
or glibc-on-ppc problem (or both). Can you test it on i386 machine
with glibc-2.3.6? Or upgrade glibc to 2.4 and test on ppc?
--
vda