ls -l segfault + [PATCH]

Jan Evert van Grootheest Jan-Evert.van.Grootheest at Vialis.nl
Mon Mar 19 07:26:46 UTC 2007


> > On Wednesday 14 March 2007 13:26, Jan Evert van Grootheest 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
> >--
> >vda
> 
> 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 :-()

Hmm, it crashes for me also with ls -la /bin...
And it doesn't crash in strace (or gdb) here too.

I was also thinking about linebuffering. But that's because I have a serial console, so getting the output flowing sooner, rather than later, is good. Denis, any comments there?

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



More information about the busybox mailing list