21–30 of 165 posts
Earlier quoted context omitted.
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!
malloc fails with ulimit
Very relevant, because containers are often under what basically is ulimit. Not that you can do much when malloc fails...
Malloc 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.
Malloc 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.
malloc fails with ulimit
Very relevant, because containers are often under what basically is ulimit. Not that you can do much when malloc fails...
Earlier quoted context omitted.
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 z…
If the out-of-memory was caused by something simple like accidentally loading 2G of data because of some odd data in an network request or a user selected file, and it rolls back to the start of the UI action or the incoming network request, the application may still work fine.
(I usually connected other out-of-resource conditions such as pipe/socket/open failures to std::bad_alloc too. They're pretty comparable in effect and give a bigger chance of actually exercising those exception paths)
(Yes, I realize Linux is the kernel, etc.)
Set VM Overcommit to zero on an embedded system with no swap (a Raspberry Pi will do nicely).
Write a C program that malloc()'s all the RAM.
Watch malloc start to fail when you hit the RAM limit and the kernel has dumped all the I/O cache it can.