malloc fails with ulimit
Very relevant, because containers are often under what basically is ulimit. Not that you can do much when malloc fails...
"graceful degradation" is one of the things worth trying.
Malloc Never Fails (2012)
11–20 of 165 posts
Re: Malloc Never Fails (2012)
#12Another thing to keep in mind, though 32 bit is less and less common over time, malloc would probably fail on a 32 bit process that is out of address space.
Raspberry Pis almost always run 32 bit OSes, so that's a common place to encounter 32-bit.
I had always thought they'd be running a 64-bit OS, given that the new hardware is 64-bit. TIL that Raspbian is still 32-bit!
Re: Malloc Never Fails (2012)
#13The title here is just blatantly false; there are certainly some scenarios in which it won't fail, but many in which it will. The author is aware of this since he fixes the claim toward the end: > To clarify, the surprising behaviour malloc has does not mean we should ignore its return value. We just need to be careful because malloc returning successfully does not always mean that we can use the requested memory. It…
> does not always mean
> if you turn overcommit off
The author said ‘does not always mean’ so giving one condition in which it does doesn’t prove them wrong does it?
Re: Malloc Never Fails (2012)
#14You can disable memory overcommit in the kernel, before any of you start assuming you can drop your malloc checks.
Re: Malloc Never Fails (2012)
#15malloc fails with ulimit
Very relevant, because containers are often under what basically is ulimit. Not that you can do much when malloc fails...
> Not that you can do much when malloc fails...
Tell the user they can’t do that operation? Use on-disk storage instead? Re-use memory you already have (such as evicting a cache and taking the memory it already had allocated)? Abandon what you were doing if it was only an optimisation and wasn’t essential (such as allocating memory as part of a speculative execution)? Run a garbage collector and try again?
Lots of options available in some situations.
Re: Malloc Never Fails (2012)
#16malloc fails with ulimit
Very relevant, because containers are often under what basically is ulimit. Not that you can do much when malloc fails...
This is true, in my experience. If you keep your program fairly simple, implement it in plain C, avoid recursion, and keep these requirements in mind from the start, then it is possible to write a program that fails gracefully when it runs out of memory. Some old-school Unix daemons do this. But for most software it's impractical, so you might as well define your own xmalloc() that calls abort() if malloc() returns zero and at least have an immediate and obvious failure, rather than obscure memory leaks and data corruption.
Re: Malloc Never Fails (2012)
#17malloc fails with ulimit
Very relevant, because containers are often under what basically is ulimit. Not that you can do much when malloc fails...
If you write code with memory exhaustion in mind, which mostly means not relying on allocations in the error handling paths, malloc fails are perfectly fine to handle.
Re: Malloc Never Fails (2012)
#18> Section III of this Phrack article is a down to earth description of how the glibc malloc implementation works, if you’re curious. This is probably outdated, given that it was written in 2009.
pocorgtfo 0x18 contains a more recent glibc malloc exploit which goes into quite a bit of detail if you're interested.
Re: Malloc Never Fails (2012)
#19The title here is just blatantly false; there are certainly some scenarios in which it won't fail, but many in which it will. The author is aware of this since he fixes the claim toward the end: > To clarify, the surprising behaviour malloc has does not mean we should ignore its return value. We just need to be careful because malloc returning successfully does not always mean that we can use the requested memory. It…
> does not always mean > if you turn overcommit off The author said ‘does not always mean’ so giving one condition in which it does doesn’t prove them wrong does it?
You're right, based on the context of the post, I was interpreting that statement to make a broader claim than it was; I've modified my comment not to contradict it.
Re: Malloc Never Fails (2012)
#20Malloc allocates virtual memory. The original article had to issue a correction at the end: "I was wrong about why malloc finally failed! @GodmarBack observes, in the comments, that x64 systems only have an address space of 48 bits, which comes out to about 131000 GB. So, on my machine at least, the malloc finally failed because of address space exhaustion."
That's incorrect, 2^48 bits = 262144GB actually.