Malloc Never Fails (2012) • Hacker News Board

Re: Malloc Never Fails (2012)

#111

Post by KirinDave » Mon, Jun 10, 2019, 3:45 PM UTC

simias wrote: post #50

mehrdadn wrote: post #27

Translation: This is a euphemism for saying Linux blatantly violates the language specification with no remorse. (Yes, I realize Linux is the kernel, etc.)

Linux is a kernel, not a C runtime so that's not really relevant. You say you realize that but then what are you arguing for exactly? Arguably you could complain that the glibc (or whatever libc you're using) is not working around that by, for instance, scrubbing the pages in malloc() to force the kernel to allocate memory. But even then I'm not convinced that anything here is non-standard, at worse maybe we're in a…

> Linux is a kernel, not a C runtime so that's not really relevant.

Maybe it's more accurate to say that Linux is a kernel that assumes many features and semantics of the C runtime. But it certainly seems more deeply intertwined than you're willing to address here.

Re: Malloc Never Fails (2012)

#112

Post by KirinDave » Mon, Jun 10, 2019, 3:49 PM UTC

mehrdadn wrote: post #38

Liquid_Fire wrote: post #34

Earlier quoted context omitted.

Which part of the specification does this violate?

Like, every part? It doesn't actually allocate the space requested, it doesn't indicate failure by returning NULL (or by any other reliable means for that matter)...

There is a deep irony in folks choosing to implement one of the few things the C standard DOES clearly define by papering over it with an alternative memory model.

Ironically, it's a memory model that greatly reduces the performance of modern systems, and als impacts its safety.

Re: Malloc Never Fails (2012)

#113

Post by 95014_refugee » Mon, Jun 10, 2019, 3:49 PM UTC

Crinus wrote: post #93

TheCondor wrote: post #75

Earlier quoted context omitted.

What is your definition of graceful in this case? Presumably there was a “business need” for the allocation and the software isn’t just allocating for fun. An allocation failure is a hard fault, it’s not possible to honor the business need so something expected to happen cannot happen. The program could segfault when the null pointer returned is written to, that is kind of crappy. It could report the error “hey we ar…

> It could report the error “hey we are out of memory and couldn’t do xyz” or better “hey we are out of memory and couldn’t do xyz, this is probably because of abc, maybe you can adjust the tuning.” What if you cannot do that report because the reporting itself needs memory that can fail? > but yes you should put a check on every toolbar allocation for two reason: one you can gracefully report why your app isn’t doin…

> Unless you are working in something like a medical or nuclear device, it is not worth to bother with such things.

Where "something like a medical or nuclear device" implies a piece of software that is expected to work correctly.

In other words, you should always ensure that failures resulting from malloc(3) returning an error (and all other errors) are suitably contained.

Re: Malloc Never Fails (2012)

#114

Post by Crinus » Mon, Jun 10, 2019, 3:56 PM UTC

95014_refugee wrote: post #113

Crinus wrote: post #93

Earlier quoted context omitted.

> It could report the error “hey we are out of memory and couldn’t do xyz” or better “hey we are out of memory and couldn’t do xyz, this is probably because of abc, maybe you can adjust the tuning.” What if you cannot do that report because the reporting itself needs memory that can fail? > but yes you should put a check on every toolbar allocation for two reason: one you can gracefully report why your app isn’t doin…

> Unless you are working in something like a medical or nuclear device, it is not worth to bother with such things. Where "something like a medical or nuclear device" implies a piece of software that is expected to work correctly. In other words, you should always ensure that failures resulting from malloc(3) returning an error (and all other errors) are suitably contained.

No, i did not implied that, please do not put words in my mouth.

My implication was software that if it fails it will kill people.

Otherwise if a program crashes because of a situation happens once every 100000000 runs, not only is worthless to worry about it, it actually is preferable to not do that as to keep the codebase clean and hence easier to maintain for bugs that actually do affect people.

Re: Malloc Never Fails (2012)

#115

Post by edoo » Mon, Jun 10, 2019, 3:59 PM UTC

I always assume malloc success and that if it were to return null the system is screwed anyway and the app will just abort. I write a lot of 'critical' C/C++ now on embedded systems with mere KB of RAM and just never use the heap ever.

Re: Malloc Never Fails (2012)

#116

Post by lmm » Mon, Jun 10, 2019, 3:59 PM UTC

unilynx wrote: post #106

lmm wrote: post #84

Earlier quoted context omitted.

If that data is read-only then a fork()ed child process will share it just as efficiently as a thread would. If your threads need to share interleaved modifications to some common state then that approach isn't viable. But in that case it will be very hard to "roll back"/"skip over" a failed request, as it's difficult to be confident that you haven't corrupted that shared data in a way that will cause the same proble…

fork only works if the central cache never updates. Eg a cache of compiled bytecode for scripts gets filled as those scripts are requested. A cache of database results fills as those results are requested. I'm not sure why skipping over failed requests is hard. VMs associated with the request are aborted, the client gets a 500/503 and can retry later. Incomplete data doesn't get added to the caches at all, so no corr…

It kind of goes both ways. If the data sharing pattern is simple then it's still quite simple to handle that at an inter-process level (e.g. perhaps you have to do cache updates via slower IPC, but if the cache updates only happen after the request has already been handled then they're not on the critical path. Or you might have the parent process handle the cache updates itself). If the data sharing pattern is complex and interleaved then it's hard to achieve with anything other than threads - but that's exactly the case that also makes it hard to avoid corrupting shared data.

Re: Malloc Never Fails (2012)

#117

Post by convolvatron » Mon, Jun 10, 2019, 4:06 PM UTC

joosters wrote: post #61

dooglius wrote: post #7

The 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…

n.b. turning over-commit off comes with its own set of problems, such as causing programs to fail long before all memory has really been exhausted. For example, fork() will have to ensure that there is enough memory for a complete copy of the running process. If you have a large process, e.g. using 4GB of a 8GB machine, then fork() won't be able to run, even if you just want to fork and run a tiny program. With over-…

cow is orthogonal to overcommit

Re: Malloc Never Fails (2012)

#118

Post by jiveturkey » Mon, Jun 10, 2019, 4:21 PM UTC

dooglius wrote: post #7

The 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…

> The title here is just blatantly false

intentionally. you don't need to point out the "error". it's a rhetorical device.

Re: Malloc Never Fails (2012)

#119

Post by jiveturkey » Mon, Jun 10, 2019, 4:25 PM UTC

brynet wrote: post #78

The malloc(3) family will absolutely fail on OpenBSD, for many reasons: login.conf/ulimits, calloc(3) for when integer overflow is detected (nmemb * size), same for OpenBSD's reallocarray extension. And yes, because the system was unable to satisfy the requested allocation. Linux overcommit, and developer mindset is a detriment to software quality and portability.

That's a needlessly confrontational statement. Yet I find myself in agreement. Sigh.

Re: Malloc Never Fails (2012)

#120

Post by fwip » Mon, Jun 10, 2019, 4:25 PM UTC

Crinus wrote: post #93

TheCondor wrote: post #75

Earlier quoted context omitted.

What is your definition of graceful in this case? Presumably there was a “business need” for the allocation and the software isn’t just allocating for fun. An allocation failure is a hard fault, it’s not possible to honor the business need so something expected to happen cannot happen. The program could segfault when the null pointer returned is written to, that is kind of crappy. It could report the error “hey we ar…

> It could report the error “hey we are out of memory and couldn’t do xyz” or better “hey we are out of memory and couldn’t do xyz, this is probably because of abc, maybe you can adjust the tuning.” What if you cannot do that report because the reporting itself needs memory that can fail? > but yes you should put a check on every toolbar allocation for two reason: one you can gracefully report why your app isn’t doin…

> What if you cannot do that report because the reporting itself needs memory that can fail?

Allocate and reserve error-reporting memory early. For example, your ErrorReporter instance is initialized at start-up, and doesn't call malloc() when you make a report.