User process memory leak, openwrt crash

I wrote a program that keeps allocating memory and after a while the device crashes, how can I stop the process that is taking a lot of memory instead of crashing?

Checked the openwrt default oom-killer configuration as follows:

root@OpenWrt:~# cat /proc/sys/vm/overcommit_memory
root@OpenWrt:~# cat /proc/sys/vm/oom_kill_allocating_task
root@OpenWrt:~# cat /proc/sys/vm/panic_on_oom

The pragmatic approach would be to fix your program not requesting unreasonable amounts of RAM. Yes, you can employ process limits and the like, but at some point something will get under memory memory pressure and fail/ get killed.

they could reboot once a day when their router is least likely to be in use.

:innocent: :rofl:

How do auto kill processes with high memory usage? Ensure that the device can continue to run.

Taking it at face value, at least trying to…

This is just affirming why daily reboots won't do anything - as things like this tend to go south very quickly, ending in a spiral of memory allocations. Rebooting once daily is unlikely to kill it in its track before the brown matter hits the fan, rebooting it every couple of minutes is too disruptive, even for Normal Joe to notice issues (and you exactly know what's causing trouble, so kill that more precisely - respectively, you've written it, fix it). And once the OOM bomb (which is more of a thermonuclear warhead, than a sniper's rifle taking out your opponent surgically) has gone off, you can't wait for the next daily reboot (nor necessary ssh in, nor expect cron to remain alive) anymore either.

1 Like

The default value will kill largest process as opposed to one process doing unsatisfialble allocation? Kind of serves your case by default.

I wrote a test program that continuously allocates memory, causing a scenario of memory leak. The default OOM killer configuration is used, and when the memory is exhausted, the device crashes.

It kills some other more important process, like dropbear or hostapd, total crash is not expected.

I configured a run led to blink every 500ms. After running the memory leak test program for a while, the memory is exhausted, and the run led stops blinking. It seems like the device has crashed.

Check syslog or serial or something, if you measure self-inflicted harm it is for you to contain consequences.

When the application keeps allocating memory, and after the memory is exhausted, the device crashes, with no output from the serial port or dmesg.

Well, you identified some of the kernel's sysctls in your first post. Why not set them to their various values and test again?

Given it's your code that's killing the device, on purpose, for what seems like an academic exercise... It's not really clear why you're asking for help.

Using the OpenWRT master branch, there is an issue with the 5.15 kernel version where there is no OOM-KILLER. Rolling back to the 5.10 kernel version resolves the issue.