Hacker News Reader

Comment by AnotherGoodName | Hacker News Reader

On Android something similar;

If you have an app that absolutely needs a lot of memory (transcoding HD videos in my case), before running it;

  - Spawn a new process and catch the unix signals for that process, specifically SIGINT. 
  - Have that new process allocate all the memory you need in your actual process. 
  - The OS will kill via it's Low Memory Killer (LMK) daemon. 
  - Since you caught the SIGINT in the parent process you can avoid the Android "Application X is using too much memory" notification that pops up to the user making it a silent failure. 
  - Lastly sleep a few MS to let Androids LMK kill other apps.

Now run your intensive memory process. This works for games too. A huge hack but needed for some of the lower end devices that don't have GB of RAM. Also needed since Java apps will just eat memory until something tells them to clean up, you need some overallocation to fail to trigger the whole memory free process on Android.

View on HN

As someone who had to tweak many times LMK and Android's way to compute which process/app has which priorities, and how is a service restarted, I want to scream very loudly. But I guess that works.

Ideally you do this in a bank app, so that when you swotch over to that PSD2 forced nonsense the app that made the payment request has died and loses the session and you get to start all over.

I've seen that shit happen on devices with >4GB of RAM. The fact that opening the bank's 2FA app can be enough to destroy the session of the app requesting payment is telling a few things:

a) phone manufacturers play ridiculous games when it comes to hiding that their SoCs are dogshit

b) so. many. apps. just outright suck at testing because they test their apps in emulators where there isn't Facebook and tons of other background crap running and thus never test their implementation of the "application is about to be killed off for lack of resources, save state to persistent storage" code path.

c) Facebook plain sucks. Their iOS app [1] and their android app [2] are both ridiculously bloated and that has led to problems well over a decade ago, and it hasn't gotten better.

d) Advertising, tracking, data mining and other spyware SDKs are just as bad as Facebook. The amount of code and RAM that each application carries just for this crap is insane, partially made worse by neither iOS nor Android supporting code deduplication and shared libraries.

[1] https://quellish.tumblr.com/post/126712999812/how-on-earth-t...

[2] https://news.ycombinator.com/item?id=28533119

I was going to ask if Android exposes mlock, which is a call that implements memory locking on normal UNIX and LINUX machines, but it looks like it is restricted to 64kb on Android.

So Android will kill your fake process.

Even when that is done, does it keep on killing other apps? Why would it do that? Because once your fake process is gone, the memory pressure is gone.

Probably tries to kill older background apps before newer services.

Yes, from what I've seen once Android start hitting memory issues it'll call onTrimMemory in all activities.

https://developer.android.com/reference/android/app/Activity...

Oh please, say more, it seems very interesting.

I didn't really get the last two bullet points

I think they are describing a "balloon" - you allocate enough memory to trigger a low-memory condition. Android then tries to kill off any large apps. You can then allocate large amounts of RAM in your own app after giving Android some time to shut down background apps, etc.

This reminds me of those "memory freer" apps they used to distribute for Windows XP. Did they actually do anything useful? Or just force Windows to write everything to the pagefile?

That could perhaps be a useful if you had just enough memory to run a game, if not for other processes using it too. In that case background services should be written to swap while running the game which will probably cause stutters. Doing it before starting the game instead would be better, if it has to be done. So such a utility might then be useful in some cases when someone couldn't afford enough RAM.

is this thre term, baloon? like baloon drive? some vm stuff, i suddenly thought it may serve similar purpose before starting a VM, those can have big memory to load in. makes sense but this is a total guess from your use of baloon. any idea by chance? :D

That's literally it. Inflate the balloon, squeeze ram, you're good to go.

When you spawn a child process you can catch the OS level events acting on the process. These are called Signals.

https://unix.stackexchange.com/questions/176235/fork-and-how...

If you wish to exit gracefully in some way (eg. cleanup) you can catch SIGINT and SIGTERM in a function in the parent process. Signals propagate unless caught. This way you can avoid the parent process (imagine a UI visible to the user) dying if you have a subprocess (memory intensive video encoding) terminated by the OS.

Signals are undertaught in CS honestly.

Er, no. You cannot catch in one process a signal posted to another. I think you might be confusing signals generated by the tty/pty, which go to the foreground process group, and signals generated by the kernel for OOMs (which go only to the victim process, not the whole group). What you can do is see what signal a child process died with (see the `wait*(2)` system calls), and with cgroups you can find out about OOM kills of processes in a cgroup, but you still can't "catch" the signal and hold the victim alive and its memory allocated for a bit.

>If you don't define an interrupt handler (or explicitly ignore the signal), both processes would just exit with a SIGINT code (the default behaviour).

That's what i mean by catching it. You either trap signal or you have the parent process exit too. The goal is to avoid the parent dying and the OS messaging the user "process killed for too much memory" which happens without the trap.

The trigger for memory is separately just to hit a failed malloc in a loop.

Thank-you both, that was what I was missing. I didn't use signals in programming in many many years, and the 'catching' of signals was the most bothering to me.

You're still confusing signals generated by the tty/pty (which go to the foreground process _group_) and OOM signals which _don't_ go to the victim process' process group. You cannot catch a signal that wasn't posted to the process or its process group -- you just cannot.

What you can do is notice via the wait syscalls that the child died with `SIGKILL`, and in a sense this is "catching" that that happened, but no signal handler runs (nor could it, since `SIGKILL` is what's used and you cannot set a handler for `SIGKILL`).

Reply on news.ycombinator.com