Re: Memory allocation troubles

["Brian J. Tarricone" <bjt23 cornell edu>]

On 10/19/04 08:23, Tristan Van Berkom wrote:
> On Tue, 19 Oct 2004 09:27:22 +0200, Olaf Fr??czyk <olaf cbk poznan pl> wrote:
> > Hi,
> >
> > I write an application that requires much memory to run.
> > It is impossible to assume that every time I ask for memory I'll get it.
> > The application creates many threads (up to several hundreds) each
> > thread taking about 0,6 MB.
> > And when I am out of memory I could just wait for some threads to
> > finish, and try again.
> > Aborting program is not an option, because before dying I need to clean
> > things up.
>
> Hmmm, 
>     I fullheartedly agree that programs should be able to run in OOM
> situations or at least handle them nicely, unfortunatly we do not represent
> a unified front to back up that notion.
>
> You can use g_try_malloc/g_try_realloc but that doesn't change behavior
> in fundimental situations such as `g_object_new'.
>
> Note that this behaviour would be very hard to change because most
> gtk+ applications depend on that behaviour (and would be segfaulting
> if that changed).

i can't speak to the difficulty of changing this, but i'm not really
seeing how the behavior change is all that different.  in the current case,
you have the app abort()ing on a failed memory allocation, and in the
other, you have the app segfaulting when they try to acess the NULL pointer
returned by gtk_foobar_new().  the only difference here is that the
user actually gets a statement printed to console that malloc() failed,
which might avoid some invalid bug reports.  either way, the end result
is the same: the app dies.

at any rate, my personal opinion on the matter is that it's a bad
programming practice not to check for (and appropriately handle!) system
errors (such as failed memory allocations).  i'm not going to say i'm
never guilty of not checking return values, but it's a pretty sloppy
practice to just kill the app when something goes wrong.  as an app
developer, i _never_ want to encounter an assert() or abort() in a
library i'm using: i expect it to report the error to me so i can
decide what to do.  (i'll admit that an out-of-memory condition is
probably the only case where i'd live with an abort().)

further, as someone else mentioned, the linux kernel will never return NULL
on a malloc() (unless specifically configured to do so).  in this case,
these apps that depend on an abort() from gtk are just going to segfault
eventually anyway.

        -brian