S>Карма у тебя такая. OOM-killer приходит к приложению своеобразным путём. Я много такого ловил, особенно на серверах под управлением особо умных админов.
Само существование OOM killer-а прекрасно показывает уровень архитектуры в линуксах.
Прикинь, в винде нету OOM killer-а. Там просто malloc возвращает нуль, если нету памяти ни в свопе ни в раме. И выделяющий память может чтото адекватное сделать, если ее вдруг не оказалось, а не тупо инициировать общесистемную эвристическую децимацию. Более того, всякие AppVerifier'ы умеют эмулировать нехватку памяти для отдельного приложения, и девелоперы имею реальную возможность такую ситуацию протестить и сделать так, чтоб ничего не падало.
Удивительно, что можно было сделать без костылей.
Да, ты можешь сказать что надо отключить overcommit, и будет хорошо. Но... тамошные быдлокодеры привыкли к overcommit да и вообще архитектура такая, что ей это надо, потому хорошо не будет

Тут пожалуй стоит добавить про странные стратегии аллокации памяти под кэши в линуксе. Такое ощущение что все это работает параллельно и монопенисуалистически относительно текущего положения дел. В результате в линуксе после активного IO память может оказаться занята файловым кэшем настолько, что последующая аллокация зафэйлится и соответственно разбушуется ООМ киллер. В ситуации когда свободной памяти мало, изза того что она вся занята кэшами, поведение ООМ киллера адекватностью не отличается.
В винде аллокация не фэйлится, а ждет освобождения (возможно со сбросом на диск) буферов. Память, занятая под файловые кэши и под подмапленные немодифицированные страницы файлов (кстати, это та же самая память), занятой не считается и никак там не ограничивает обычные аллокации.