Re:When the memory allocator works against you
by mikeash on Sunday March 12, 2017 @01:59PM
(#13851992)
Tha program that hits a malloc failure will not necessarily be the program that ate up all the RAM.
Re:When the memory allocator works against you
by tedunangst on Sunday March 12, 2017 @02:09PM
(#13852069)
Malloc failure is at least synchronous with the out of memory condition. And if your program has reached a fixed state, it may not even be calling malloc.
Re:When the memory allocator works against you
by cturner on Sunday March 12, 2017 @03:30PM
(#13852550)
Ot: your flak blog could benefit from a page showing links to all articles. Currently, hard to read beyond 'recent'.
Re:When the memory allocator works against you
by tedunangst on Sunday March 12, 2017 @03:36PM
(#13852593)
Don't waste your time with the old crap. :)
Re:When the memory allocator works against you
by paulddraper on Sunday March 12, 2017 @03:01PM
(#13852383)
Sure, but (a) it can handle the malloc failure and (b) it's pretty easy for the user to find the bad guy.
Re:When the memory allocator works against you
by deathanatos on Sunday March 12, 2017 @05:50PM
(#13853337)
It might handle the malloc failure by crashing. Some languages (e.g., Rust) and runtimes (e.g., glib) presume that small allocations always succeed; a failure in such an allocation immediately crashes the program (as the underlying API provides no means to report the failure).
Re:When the memory allocator works against you
by steveklabnik on Sunday March 12, 2017 @10:26PM
(#13854777)
Rust the language doesn't know anything about allocation; it's entirely a standard library decision.
...and it would be absurd for bad programs to eat memory and crash? We must have other programs pay for its sins?