Replying to multiple messages in one.
>> Well, wasting memory at run-time is inherent in the design of busybox.
>
> Only on machines which cannot share text segment.
Sorry, but this whole discussion exists only because the data/bss is
bigger than it needs to be for any single applet.
Denys Vlasenko wrote:
> On Monday 09 June 2008 12:55, Bernd Schmidt wrote:
>>> IOW: crypt() which uses static buffers is as likely
>>> to die/lock up on OOMing machine as malloc() based one.
>> Incorrect on some systems, notably nommu which is quite a likely setup
>> for uClibc. Also, an order-5 malloc on nommu is much more likely to
>> fail than taking an order-0 page fault on mmu. A 70k allocation _will_
>> fail occasionally, even on systems that have plenty of memory free.
>
> In this situation, execv'ing of an application with additional 70k
> of static buffers will fail even more readily, right? Because
> you do not require two smaller contiguous areas
> (N kb for app and 70k for buffer) but one contiguous area of N+70 kb.
Sigh. Yes, and that's the desired behaviour. From the execve manpage:
ERRORS
[...many...]
ENOMEM Insufficient kernel memory was available.
From the crypt manpage:
ERRORS
ENOSYS The crypt() function was not implemented, probably
because of U.S.A. export restric‐
tions.
It's really not a hard concept, this whole documented behaviour thing.
>> and infinitely better
>> > than crashing in the middle of a program and leaving things in an
>> > inconsistent state. Even when you get OOM, there are different modes of
>> > failure,
>
> On the microscopic level, yes, they are different.
>
> In a bigger picture, no. The machine is unusable one way or another.
But what are the consequences of failure? Okay, so I agree that a
production machine should be big enough not to go OOM. Reality is more
difficult, maybe there's a memory leak somewhere, in any case OOM does
happen occasionally. The question then becomes: where and how do we
fail, and what are the consequences. Do we fail at a point where the
possibility of a memory allocation failure (or other hard error) is
documented and can be dealt with, or do we fail in a random place? In
one of these cases it's possible to engineer a certain measure of
robustness, in the other case it's impossible. The machine may be
unusable in both cases, but in one case the damage can be contained more
effectively.
There are computers which run software that is more complex than
busybox, where it's not just a question of the user experience of
printing "out of memory" on a shell prompt.
With that, I'll give up on convincing you; unless someone else objects
soon I'll take Bernhard's and Daniel's messages as consensus to start
fixing things.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
