[Webkit-unassigned] [Bug 205346] [GTK ] abort on memory allocation failure

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=205346

Michael Catanzaro <mcatanzaro at gnome.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Michael Catanzaro <mcatanzaro at gnome.org> ---
What I meant to suggest was to report a bmalloc bug to figure out why allocation is failing more regularly than with system malloc. Trying to change memory allocation failures to be non-fatal would not be practical.

(In reply to Haelwenn (lanodan) Monnier from comment #0)
> Well I guess it could use g_try_malloc() (which returns NULL on fail)
> instead to avoid the call to abort by GLib. Sadly IIRC it needs some large
> changes in WebKitGTK code so I don't think I'll be able to provide a patch
> as I don't have much time and basically no infra.

There is no point to trying this. GLib itself uses g_malloc(), GTK uses g_malloc(), probably the vast majority of the libraries that we depend on use g_malloc(). Very few libraries are constructed to allow non-fatal memory allocation failure: Fontconfig and GnuTLS come to mind as notable exceptions. So if (almost) all the libraries that use WebKit abort on memory allocation failure, and certainly all the applications that use WebKit also do (because they use GTK), there is zero value in trying to change WebKit to avoid this, right?

Even if we were to change every library we depend on, it would be prohibitively difficult to change this. Most function calls would need to become fallible, which means changing the API of most functions, and handling allocation failures in tens or hundreds of thousands of places that don't currently, and then errors when those functions fail unexpectedly due to OOM condition. Generally it won't be possible to handle the errors in sane ways. You could spend millions to fund a large team of developers to work on this for years and all we'd accomplish would be making the codebase harder to read.

So I wouldn't use vm.overcommit_memory = 2 unless you're sure you won't run out of RAM.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191217/59b470d6/attachment.htm>