[solved?] Re: vi segfaults (bb 1.8.2)

Denys Vlasenko vda.linux at googlemail.com
Sun Dec 9 04:06:43 UTC 2007


Hi Christian,

_Excellent_ analysis!

On Wednesday 05 December 2007 07:24, Cristian Ionescu-Idbohrn wrote:
> It seems to be caused by the poor correlation control between BUFSIZ,
> COMMON_BUFSIZE and MAX_LINELEN and somewhat poor choice of macro
> names. In this case:
>
> ,---- [ include/libbb.h ]
>
> | 1101: #ifndef BUFSIZ
> | 1102: #define BUFSIZ 4096
> | 1103: #endif
>
> `----
>
> BUFSIZ is present in bb 1.8.2 but seems to have gone away on svn-head.

No. Believe it or not, BUFSIZ (what a wonderful name...) is a part
of libc API.

> What happens is that uclibc (in my case 0.9.27) also has a BUFSIZ
> macro.  And it's value is set to 256 (in my code tree).

uclibc makes it configurable in order to reduce memory consumption
if needed.

> Building bb 
> with uclibc (configured that way) could have unpleasent side effects,
> like segfaults.

...if programs assume that BUFSIZ is always bigger than N bytes.

> In my 'vi' segfault case, the following macros are involved:
>
> BUFSIZ=256, COMMON_BUFSIZE=1024,
> CONFIG_FEATURE_VI_MAX_LEN=2048, MAX_LINELEN=2048

Last two are the same (grep for them in vi.c)

> COMMON_BUFSIZE is set to 1024 by:
>
...
>
> At run time, these buffers (pointer values below) are involved:
>
>   readbuffer=0x000dfad8
>   ptr_to_globals=0x000e0008
>
> and n=1.
>
> On this line:
>
> ,---- [ editors/vi.c ]
>
> | 2257         memmove(readbuffer, readbuffer + n, MAX_LINELEN - n);
>
> `----
>
> in function 'readit', when 'readbuffer' is shifted 1 byte down, 2047
> bytes get shifted instead of 1023, and (part of) 'globals' gets also
> shifted, as in my case 'globals' starts some 1460 away from
> 'readbuffer'.

You nailed it down.

> In order to avoid this brakage without changing the code (still
> talking about bb 1.8.2), the workaround, in my case, is to both set
> BUFSIZ to a reasonable value in my wrapper Makefile and also correlate
> that with a good value for CONFIG_FEATURE_VI_MAX_LEN in bb .config.

It's simpler than that. Programs should not make assumptions that
BUFSIZ is bigger than some fixed number. (Well, probably you can
be sure that it is bigger than, say, 63 :) ).

Our vi was making that bad assumption. Please try attached patch.
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.patch
Type: text/x-diff
Size: 1285 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20071208/1a2eaedf/attachment-0002.bin 


More information about the busybox mailing list