[Mono-bugs] [Bug 324318] Handling of out of memory issues

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=324318#c2


Paolo Molaro <lupus at novell.com> changed:

           What    |Removed                                         |Added
----------------------------------------------------------------------------
            Summary|Too many heap sections exception when adding    |Handling of out of memory issues
                   |many elements to a hashtable.                   |




--- Comment #2 from Paolo Molaro <lupus at novell.com>  2007-09-24 08:48:19 MST ---
I had to change the num value to 30000000 to make the issue appear on my box.
I increased the number of allowed heap sections, so that specific message is
not (or shouldn't be) hit anymore.
What will happen then with the test program is that memory is completely filled
up and there is no more room even for malloc() so the rest of the runtime will
start failing instead in the glib allocations. Things behave much better if you
add to the hash objects of 2-4 MB in size: there is a much better chance that
there is enough memory for malloc in the runtime to be able to actually throw
the out of memory exception and print the eventual error to the console.
I'll use this bug report to summarize the issues that need addressing.

Managed out of memory handling: this is the easy part, since much of it is
handled already. The things that need checking for are the parts of the runtime
where a managed allocation happen in critical cases. In managed code a critical
case is for example inside finalizers: getting the exception may result in
leaked resources. In unmanaged code we have the cases where we may have
allocated managed memory with a lock taken (making the jump to managed code
will result in deadlocks) or data structures allocated that won't be freed
since we'd go to managed code to handle the out of memory exception.
It may be worth it to not hook to the out of memory callback the Boehm GC
provides, but check for NULL in all the places where we allocate and handle the
cases differently if need (thhrowing the exception if it is safe to do, or
doing some cleanup etc).
To be able to test these cases, we need to change the GC to fail allocations
after a while, depending on an env var (this would be a debug build, since this
is expensive) and running the test suite, making sure we always get the proper
exception and not runtime crashes (of course specific tests will be good, too).

The unmanaged memory allocation failures will be harder to handle. First we
need to get rid of GLib and its associated memory functions, so we'd have
complete control on what happens when an allocation fails. Then we need to
transition to
checking every allocation, instead of the current behaviour of just giving up.
For testing the same mechanism as above could be useful here: the new alloc
routines could be instrumented to fail allocations after N allocations.
Many APIs will need changes so we can propagate errors up the call chain.


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.