As explained in issue #585, if an application's malloc() attempt fails
because of lack of memory, we abort inside the "reclaimer thread", making
it hard to debug where in the application the OOM actually happened.
This patch doesn't solve the whole problem, but solves an important
special case: If the application tries to allocate a ridiculous amount,
larger than the entire VM memory, with this patch the abort will happen
during the allocation attempt, making it easy to debug where the
application did the wrongly-sized malloc().
Signed-off-by: Nadav Har'El <n...@scylladb.com>
---
core/mempool.cc | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/core/mempool.cc b/core/mempool.cc
index 9f37963..0b1e69e 100644
--- a/core/mempool.cc
+++ b/core/mempool.cc
@@ -528,6 +528,12 @@ void reclaimer::wait_for_minimum_memory()
// memory, there is very little hope and we would might as well give up.
void reclaimer::wait_for_memory(size_t mem)
{
+ // If we're asked for an impossibly large allocation, abort now instead of
+ // the reclaimer thread aborting later. By aborting here, the application
+ // bug will be easier for the user to debug. An allocation larger than RAM
+ // can never be satisfied, because OSv doesn't do swapping.
+ if (mem > memory::stats::total())
+ abort("Unreasonable allocation attempt, larger than memory.
Aborting.");
trace_memory_wait(mem);
_oom_blocked.wait(mem);
}
--
2.7.4
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
