Re: Memory allocation problem

On 2007/11/03, John Hasler wrote:
Puzzled writes:

From the malloc man page:

"By default, Linux follows an optimistic memory allocation strategy.
This means that when malloc() returns non-NULL there is no guarantee
that the memory really is available. This is a really bad bug."

And it's bit me.

No it hasn't. Read the rest of that note.

I did. And the files in the kernel Documentation/vm direcxtory. And

Does anyone have any ideas about this?

Post your code.


I avoided that because it would cause a lot of irrelevant chatter, but
having no other recourse, I pasted it in here. *Then* I found the code
that triggered the problem. The program's working fine now.

But the malloc() bug is still there. What test can I apply to it?
The "optimistic strategy" is decribed as the "default". Can malloc()
be switched to a robust strategy? (I tried setting the environment
variable MALLOC_CHECK_ to 1 but that didn't help.)

Why does such a bug exist? Memory allocation is a mission-critical
system service even for trivial programs: why is Linux malloc()
*deliberately* frail?

How can anyone develop credible and portable software when such a
basic service is so unreliable that even its own man page describes
it as having a "really bad bug"?

I remain,

very, very, very,


Relevant Pages

  • malloc, __nogc new , _CrtCheckMemory in managed c++
    ... my question is about malloc, can i use malloc in the unmanaged part? ... i just want to know if malloc can cause some bug. ... one more thing about catching bug when unmanaged memory allocation involved, ...
  • Re: ZLib double free bug: Windows NT potentially unaffected
    ... I've been researching this bug since I heard that ssh passes packets to zlib ... Double free vulnerabilities are primarily an issue for malloc implementations ... how exploitation of this error works entitled: ... Also as noted above some malloc libraries have explicit protection mechanisms ...
  • Re: A different proposal
    ... that OpenSSL's malloc was significantly to blame. ... _severity_ of the bug. ... length of this data to determine the size of your payload, the spec _also_ ... Updates to ports are inherently slower than patches from the OpenSSL team. ...
  • Re: Heartbleed (was ... Re: My fellow (Debian) Linux users ...)
    ... says that both he and a reviewer missed the bug. ... depending on developers to review their own work is not a good idea. ... But around that time OpenSSL adds a wrapper around malloc & free so ...
  • Re: Heartbleed (was ... Re: My fellow (Debian) Linux users ...)
    ... the OpenSSL developer who claims responsibility for ... says that both he and a reviewer missed the bug. ... But around that time OpenSSL adds a wrapper around malloc & free so ... that the library will cache memory on it's own, and not free it to the ...