ls -l segfault + [PATCH]

[Harald Küthe]

Hello List, Jan,

> 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 :-()

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

Best regards
Harald