Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > xmalloc string functions

Reply
Thread Tools

xmalloc string functions

 
 
William Ahern
Guest
Posts: n/a
 
      01-28-2008
Yevgen Muntyan <(E-Mail Removed)> wrote:
<snip>
> I'd think evolution crashed because it crashed. You can look at
> its list of bugs to see what I mean. If it was abort() inside
> g_malloc(), then it probably leaked so much that it indeed has
> eaten everything and asked for more. In which case you can't
> really blame glib


Actually, it was usually Galeon/Gecko which leaked, or rather whose leaks
would begin to trigger out-of-memory errors. But that's beside the point.
I'd much rather that Evolution fail to open a message than to exit entirely.

> (Here I'd be actually grateful if such applications were killed
> immediately, because they first freeze X, and I've got to wait
> for ten minutes to switch to console and kill the application.
> They just don't die themselves.)


If these were the only choices (crashing applications or a frozen screen),
I'd be more agreeable.

There were many bad spots in Evolution, but mostly the code was OK (I've
combed through much of it). Evolution had to deal with bad UTF encodings,
malformed MIME, networks coming up and going down. Handling memory
allocation failures would hardly add much in the way of complexity or
effort.

> >
> > In my experience, glib-based applications "mostly" work. Not sure whether
> > that has more to do w/ the xmalloc() wrapper, or other issues.


> There is no xmalloc() wrapper in glib. Anyway, have you never
> seen "mostly working" application which do not use glib? Bugs
> are everywhere, on all platforms. Do you have a real base for
> saying that g_malloc() is somehow responsible for crashes you
> have seen? Something other than "evolution crashed", that is,
> or "similar applications" (similar glib-based applications
> which open messages, huh?).


I know for a fact that Evolution and similar applications have exited
because their malloc wrapper decided to exit. They've also crashed for
numerous other reasons. Bugs are bugs, but defective by design is hardly
excusable.

Exiting on malloc failure makes sense for a utility like sort(1). It doesn't
make sense for desktop applications, unless there's a separate strategy,
like a multi-process configuration where a component exiting is part of the
design of handling errors and making a best-effort recovery.

It makes sense for sort(1) because it categorically cannot perform its task
on a failure. And its practical because sort is usually just a sub-component
in a larger work. Sort can exit without killing the script or application
which called it.

> You know, I have heard things like you are saying only from
> people who talk about xmalloc() and related things. Never from
> users. Why is that? Perhaps because buggy applications are
> buggy applications, not some poor creatures crashing because
> glib memory handling is broken?


Users are, sadly, inured to this issue. Nor can they discern the reason for
failure, so they aren't capable of judging the cost/benefit of any
particular behavior.

You sort of missed part of my point regarding Evolution. What I was
experiencing was a denial of service caused by processing untrusted data.
And by using glib you have no recourse. Indeed, much of glib's functionality
is simply a rehash of, by now, widely supported library interfaces, but with
the feature of exiting when memory becomes tight.

<snip>
> > One of my rules of thumb is that if a network daemon uses glib, I
> > automatically exclude it from consideration. I can deal when an application
> > crashes and destroys my work. I don't want to be responsible for installing
> > an application which crashes and destroys or interrupts _other_ people's
> > work.


> It's fine, nobody promiced glib will work for any program. It certainly
> won't; but nevertheless it doesn't make abort-on-failing-malloc less
> sensible strategy for a whole class of applications.


The problem is that such a strategy is usually the wrong one for the class
of applications which glib serves: desktop applications, and increasingly
network daemon services. Both of those usually involve monolithic
applications doing complex tasks for which memory allocation failure is only
one of dozens or hundreds of exceptional conditions. And yet out of all of
them people will argue memory allocation alone can be completely ignored,
simply because it's too burdensome.

> Besides, a glib application can set up some sort of emergency memory
> pool or something, so that failed malloc doesn't necessarily lead to
> immediate abort(). Same sort of science fiction as "graceful exit with
> saving data on *any* failed malloc() call in any possible application
> in any possible situation" which seems to be so popular here


It's not science fiction. It's just difficult. And sometimes the answer
involves not using C, rather than using C and choosing not to address the
problem.

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      01-28-2008
Kelsey Bjarnason wrote:
> [...]
> You persist in demonstrating you have no concept at all how to design
> software.


Malcolm believes that an assembly line worker with a hangnail
is within his rights to halt the entire factory, no matter what
the rest of the team might think.

Malcolm believes that a private whose rifle jams is justified
in surrendering his whole country, no matter what the generals and
presidents and commissars say.

Malcolm believes that one fouled spark plug should announce its
difficulty by blowing the whole car to smithereens.

Malcolm -- oh, what's the use?

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid
 
Reply With Quote
 
 
 
 
Randy Howard
Guest
Posts: n/a
 
      01-28-2008
On Sun, 27 Jan 2008 09:49:42 -0600, Kelsey Bjarnason wrote
(in article <(E-Mail Removed)>):

> On Sun, 27 Jan 2008 20:34:58 +0000, Yevgen Muntyan wrote:
>
>> Malcolm McLean wrote:
>>> Here are six functions implemented on top of xmalloc(). No C programmer
>>> should have any triouble providing the implemetations, though replace
>>> and getquote are non-trivial.

>>
>> [snip]
>>
>>> I've think we've got something quite powerful here, purely because none
>>> of these functions can ever return null for out of memory conditions.
>>> It massively simplifies string handling.

>>
>> Take a look at glib,
>> http://library.gnome.org/devel/glib/...llocation.html

>
> Oh, good God. They didn't. Tell me they didn't.
>
> One wonders how many applications they've screwed over with that bit of
> asinine idiocy.


Sure. That's why seeing an app crash on a linux box is "no big
surprise" anymore. It's also one of the reasons I don't run Linux
anymore except when I absolutely have to. It's not the kernel's fault,
but it is a problem with the normal way the platform is deployed.

> Malcolm should go work for them. He'd love it. "Errors? We don't do
> errors, we just crash the app. Enjoy another piece of quality software
> from the Gnome team."


Do they employ anyone at all?


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw





 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-28-2008
Randy Howard wrote:
> On Sun, 27 Jan 2008 09:49:42 -0600, Kelsey Bjarnason wrote:
>>
>> One wonders how many applications they've screwed over with that bit of
>> asinine idiocy.

>
> Sure. That's why seeing an app crash on a linux box is "no big
> surprise" anymore. It's also one of the reasons I don't run Linux
> anymore except when I absolutely have to. It's not the kernel's fault,
> but it is a problem with the normal way the platform is deployed.
>

<OT>Unlike some other platforms, Linux and UNIX platforms in general
offer the user a choice of desktop environments. One popular
alternative is written in TOL, which is better equipped to manage
dynamic memory</OT>

--
Ian Collins.
 
Reply With Quote
 
Yevgen Muntyan
Guest
Posts: n/a
 
      01-28-2008
William Ahern wrote:
> Yevgen Muntyan <(E-Mail Removed)> wrote:
> <snip>
>> I'd think evolution crashed because it crashed. You can look at
>> its list of bugs to see what I mean. If it was abort() inside
>> g_malloc(), then it probably leaked so much that it indeed has
>> eaten everything and asked for more. In which case you can't
>> really blame glib

>
> Actually, it was usually Galeon/Gecko which leaked, or rather whose leaks
> would begin to trigger out-of-memory errors. But that's beside the point.
> I'd much rather that Evolution fail to open a message than to exit entirely.
>
>> (Here I'd be actually grateful if such applications were killed
>> immediately, because they first freeze X, and I've got to wait
>> for ten minutes to switch to console and kill the application.
>> They just don't die themselves.)

>
> If these were the only choices (crashing applications or a frozen screen),
> I'd be more agreeable.
>
> There were many bad spots in Evolution, but mostly the code was OK (I've
> combed through much of it). Evolution had to deal with bad UTF encodings,
> malformed MIME, networks coming up and going down. Handling memory
> allocation failures would hardly add much in the way of complexity or
> effort.


[snip]

> The problem is that such a strategy is usually the wrong one for the class
> of applications which glib serves: desktop applications, and increasingly
> network daemon services. Both of those usually involve monolithic
> applications doing complex tasks for which memory allocation failure is only
> one of dozens or hundreds of exceptional conditions.


This is very very wrong. A typical GUI application does not do a
switch like

switch (problem_to_handle)
{
....
}

to which you could add

case ALLOC_FAILED:

It's usually different, you got the main loop which
got to spin, you got those controls you got to draw,
and you got those callbacks which actually do the
job. And the callbacks do one thing at a time, they
do not handle dozens of exceptional conditions at once,
they do not handle exceptional conditions at all
in fact.

> And yet out of all of
> them people will argue memory allocation alone can be completely ignored,
> simply because it's too burdensome.


No, because the effort would be gigantic, you would still fail to
do it properly, and at the end it would bring no benefit.

How would you test it? Imagine a toolkit which doesn't abort
on memory allocation failure: why would you have a slightest
reason to believe that given application won't just segfault
on malloc() failure? (The question which applies to all
applications which do try to handle malloc failure of course).
What you can be sure about is that there would be more chances
for an application to screw up and actually corrupt your data
or display wrong data.

All you can sensibly do on malloc() failure is to kill the
application. Maybe save the data you can save or something
(which you can do with glib). What else? Say, if malloc() failed
when the main loop code tries to process an event from Xlib, it
can start fail silently, it can be killed by an x error because
it failed to take into account some data it got (timestamp?),
it can grab the mouse and lock the X server, it can do many
other nasty things I can't make up right now.

Or, if malloc() failed when you tried to show a dialog telling
the user he got to call his mama, he won't call his mama! (Yes,
if the application crashed, the user will restart it, see the
dialog, and call his mama, users are like that. Those users who
are lucky enough to see an application aborting because memory
allocation failed. Randy Howard, you, and perhaps few other
people from comp.lang.c

Of course I am talking about "small" allocations here, not
about stuff like allocating memory to load an image file (for
those g_malloc() is simply not used).

Perhaps in ideal world with ideal toolkits things would
be different, don't know about that. But I do know that
while dumb abort() is not the best possible solution,
talking about how it is easy to do things differently is
just a child talk. "Of course I would do it better!" Yeah.

Regards,
Yevgen
 
Reply With Quote
 
Yevgen Muntyan
Guest
Posts: n/a
 
      01-28-2008
Ian Collins wrote:
> Randy Howard wrote:
>> On Sun, 27 Jan 2008 09:49:42 -0600, Kelsey Bjarnason wrote:
>>> One wonders how many applications they've screwed over with that bit of
>>> asinine idiocy.

>> Sure. That's why seeing an app crash on a linux box is "no big
>> surprise" anymore. It's also one of the reasons I don't run Linux
>> anymore except when I absolutely have to. It's not the kernel's fault,
>> but it is a problem with the normal way the platform is deployed.
>>

> <OT>Unlike some other platforms, Linux and UNIX platforms in general
> offer the user a choice of desktop environments. One popular
> alternative is written in TOL, which is better equipped to manage
> dynamic memory</OT>


You mean those application will abort in the unexpected exception
handler instead of inside g_malloc()? Sure, that's certainly better.
 
Reply With Quote
 
Randy Howard
Guest
Posts: n/a
 
      01-28-2008
On Sun, 27 Jan 2008 20:42:05 -0600, Yevgen Muntyan wrote
(in article <1ibnj.6922$fs4.1427@trnddc02>):

> Ian Collins wrote:
>> Randy Howard wrote:
>>> On Sun, 27 Jan 2008 09:49:42 -0600, Kelsey Bjarnason wrote:
>>>> One wonders how many applications they've screwed over with that bit of
>>>> asinine idiocy.
>>> Sure. That's why seeing an app crash on a linux box is "no big
>>> surprise" anymore. It's also one of the reasons I don't run Linux
>>> anymore except when I absolutely have to. It's not the kernel's fault,
>>> but it is a problem with the normal way the platform is deployed.
>>>

>> <OT>Unlike some other platforms, Linux and UNIX platforms in general
>> offer the user a choice of desktop environments. One popular
>> alternative is written in TOL, which is better equipped to manage
>> dynamic memory</OT>

>
> You mean those application will abort in the unexpected exception
> handler instead of inside g_malloc()? Sure, that's certainly better.


Is there some reason you have been appointed as glib's public defender?




--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw





 
Reply With Quote
 
Yevgen Muntyan
Guest
Posts: n/a
 
      01-28-2008
Randy Howard wrote:
> On Sun, 27 Jan 2008 20:42:05 -0600, Yevgen Muntyan wrote
> (in article <1ibnj.6922$fs4.1427@trnddc02>):
>
>> Ian Collins wrote:
>>> Randy Howard wrote:
>>>> On Sun, 27 Jan 2008 09:49:42 -0600, Kelsey Bjarnason wrote:
>>>>> One wonders how many applications they've screwed over with that bit of
>>>>> asinine idiocy.
>>>> Sure. That's why seeing an app crash on a linux box is "no big
>>>> surprise" anymore. It's also one of the reasons I don't run Linux
>>>> anymore except when I absolutely have to. It's not the kernel's fault,
>>>> but it is a problem with the normal way the platform is deployed.
>>>>
>>> <OT>Unlike some other platforms, Linux and UNIX platforms in general
>>> offer the user a choice of desktop environments. One popular
>>> alternative is written in TOL, which is better equipped to manage
>>> dynamic memory</OT>

>> You mean those application will abort in the unexpected exception
>> handler instead of inside g_malloc()? Sure, that's certainly better.

>
> Is there some reason you have been appointed as glib's public defender?


I don't like smart arses who know nothing except how to use
word "idiot" and its derivatives. Not that glib needs to be
defended of course, since it's something that actually works
in real world, not like those smarties' smart ideas.

My original intention really was just to point out that
Malcolm ideas are not something unusual or broken by definition.
But then I read the replies, and replied myself, and I should
stop right here!

Yevgen
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-28-2008
Yevgen Muntyan wrote:
> Ian Collins wrote:
>> Randy Howard wrote:
>>> On Sun, 27 Jan 2008 09:49:42 -0600, Kelsey Bjarnason wrote:
>>>> One wonders how many applications they've screwed over with that bit
>>>> of asinine idiocy.
>>> Sure. That's why seeing an app crash on a linux box is "no big
>>> surprise" anymore. It's also one of the reasons I don't run Linux
>>> anymore except when I absolutely have to. It's not the kernel's
>>> fault, but it is a problem with the normal way the platform is deployed.
>>>

>> <OT>Unlike some other platforms, Linux and UNIX platforms in general
>> offer the user a choice of desktop environments. One popular
>> alternative is written in TOL, which is better equipped to manage
>> dynamic memory</OT>

>
> You mean those application will abort in the unexpected exception
> handler instead of inside g_malloc()? Sure, that's certainly better.


No, I mean the application can choose where in the call chain to catch
memory allocation failures and take appropriate action. It can also use
appropriate techniques not available to a C application to manage the
lifetime of allocated memory, reducing the risk of leaks leading to
premature memory exhaustion.

--
Ian Collins.
 
Reply With Quote
 
Yevgen Muntyan
Guest
Posts: n/a
 
      01-28-2008
Ian Collins wrote:
> Yevgen Muntyan wrote:
>> Ian Collins wrote:
>>> Randy Howard wrote:
>>>> On Sun, 27 Jan 2008 09:49:42 -0600, Kelsey Bjarnason wrote:
>>>>> One wonders how many applications they've screwed over with that bit
>>>>> of asinine idiocy.
>>>> Sure. That's why seeing an app crash on a linux box is "no big
>>>> surprise" anymore. It's also one of the reasons I don't run Linux
>>>> anymore except when I absolutely have to. It's not the kernel's
>>>> fault, but it is a problem with the normal way the platform is deployed.
>>>>
>>> <OT>Unlike some other platforms, Linux and UNIX platforms in general
>>> offer the user a choice of desktop environments. One popular
>>> alternative is written in TOL, which is better equipped to manage
>>> dynamic memory</OT>

>> You mean those application will abort in the unexpected exception
>> handler instead of inside g_malloc()? Sure, that's certainly better.

>
> No, I mean the application can choose where in the call chain to catch
> memory allocation failures and take appropriate action.


Sweet theory. And where is that, main()? Or where do you call the
function/method which starts the main loop? And, more importantly,
which so-much-better other-toolkit applications actually do this?
And, what of the above is impossible in C with glib (since we talk
theory here, not what applications really do)?

> It can also use
> appropriate techniques not available to a C application to manage the
> lifetime of allocated memory, reducing the risk of leaks leading to
> premature memory exhaustion.


True. The Other Language does have nice things. But then the
Other Language is better (if better) not because of some glib,
but because of the language features

Yevgen
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
xmalloc.c - my xmalloc vippstar@gmail.com C Programming 11 02-20-2008 12:34 AM
xmalloc Malcolm McLean C Programming 52 06-27-2007 08:44 PM
Multi-threaded C++, new, and xmalloc Tim Hollingsworth Ruby 4 11-24-2006 05:02 PM
please help me in distinguish redefining functions, overloading functions and overriding functions. Xiangliang Meng C++ 1 06-21-2004 03:11 AM
[OT?] xmalloc Jeff C Programming 10 07-07-2003 05:14 PM



Advertisments