ls -l segfault + [PATCH]

[Jan Evert van Grootheest]

Denis,

> 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?

I'm on i386 with glibc 2.3.6.

With strace the ls succeeds. And the writes are prefectly 8192 bytes. My /bin directory is 2 full buffers and some 6k.
I'll try the glibc allocated buffer and let you know.

-- Jan Evert 
 
The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. Vialis is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.