Attempt to fix OOM crashes. 88/214588/1
authorMichal Bloch <m.bloch@samsung.com>
Mon, 23 Sep 2019 12:04:45 +0000 (14:04 +0200)
committerHyotaek Shim <hyotaek.shim@samsung.com>
Tue, 24 Sep 2019 07:19:57 +0000 (07:19 +0000)
Change-Id: I8ffb1fc2b4d7bc5a95065e7cd0124516fe2a1797
Signed-off-by: Michal Bloch <m.bloch@samsung.com>
(cherry picked from commit 05186018152f8d269b9ccec21f9ad90f44894b9d)
(cherry picked from commit 6132dfe4af99742e23a978955852cc16494043fd)

src/memory/memory-killer.c

index 51034964374e473279c98d26b8f7c6b345df5342..43834c44650b20eb13214663b20afafe16f4af78 100644 (file)
@@ -140,7 +140,11 @@ static int memory_killer_get_candidates(enum memory_killer_range range, GSList *
                if (getpgid(pid) == 0)
                        continue;
 
-               candidate = g_new(struct memory_killer_candidate, 1);
+               /* Using the `try` version here is mostly wishful thinking because there's a call
+                * to `g_slist_prepend` below which can call `g_malloc` (the non-try version)
+                * internally  and will most likely crash anyway in a low memory environment with
+                * no way to control it. Sometimes we can get lucky and avoid a crash though. */
+               candidate = g_try_new(struct memory_killer_candidate, 1);
                if (!candidate) {
                        _E("Not enough memory");
                        g_slist_free_full(*candidates, g_free);
@@ -192,7 +196,12 @@ static int memory_killer_get_candidates(enum memory_killer_range range, GSList *
        }
 
        closedir(dp);
-       return 0;
+
+       /* I don't think it is possible for no elements to be on the list at this point.
+        * Consider that at least resourced itself should be present. That said, it's
+        * good to be future-proof in case the candidate list gets some smart filtering
+        * in the future or something like that. */
+       return *candidates ? 0 : -ENOENT;
 }
 
 /**