News for hackers. Stuff that matters.
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.
Re:When the memory allocator works against you by mikeash on Sunday March 12, 2017 @09:19PM (#13854494)
(a) it probably won't therefore (b) the "bad guy" is going to be most/all processes.