| Summary: | [GTK] Web processes should not have unlimited access to memory | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> | ||||||||
| Component: | WebKitGTK | Assignee: | Michael Catanzaro <mcatanzaro> | ||||||||
| Status: | NEW --- | ||||||||||
| Severity: | Normal | CC: | andersca, bitlord0xff, bugs-noreply, cgarcia, clopez, dbates, jdiggs, kapouer, mcatanzaro, mrobinson, sam | ||||||||
| Priority: | P2 | ||||||||||
| Version: | 528+ (Nightly build) | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=146794 https://bugzilla.redhat.com/show_bug.cgi?id=1247540 |
||||||||||
| Attachments: |
|
||||||||||
|
Description
Michael Catanzaro
2015-07-09 10:35:49 PDT
Created attachment 256489 [details]
Patch
Comment on attachment 256489 [details]
Patch
What happens when a WebProcess hits this limit? Does it crash?
(In reply to comment #2) > Comment on attachment 256489 [details] > Patch > > What happens when a WebProcess hits this limit? Does it crash? It causes mmap() to return ENOMEM. If that happens to WTF::OSAllocator, it will immediately call CRASH(). Other call sites could handle it differently, of course. In practice, with my reproducer, the web process loads for some time (30-45 seconds) and then crashes. Comment on attachment 256489 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=256489&action=review > Source/WebKit2/Shared/unix/ChildProcessMain.cpp:62 > + // The address space limit is currently set to 5 GB. In practice, this causes a runaway web > + // process to cap out at about 1.4 GB of allocated memory. > + static const auto addressSpaceLimitBytes = 5000000000l; > + rlimit64 rlim = {addressSpaceLimitBytes, addressSpaceLimitBytes}; > + rlim.rlim_max = rlim.rlim_cur; > + if (setrlimit64(RLIMIT_AS, &rlim)) I think that we should allow at runtime to tune this limit as also to disable any limit check. Maybe with an environment variable? Good idea. An environment variable sounds best. Do you prefer something short like WEBKIT_CHILD_RLIMIT_AS or WEBKIT_CHILD_ASLIMIT, or something more descriptive like WEBKIT_CHILD_ADDRESS_SPACE_LIMIT? If set to 0 the limit would be disabled, otherwise it would be applied in bytes. Comment on attachment 256489 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=256489&action=review > Source/WebKit2/Shared/unix/ChildProcessMain.cpp:46 > +void ChildProcessMainBase::setProcessResourceLimits() Only resource this limits is memory, no? I would call it setMemoryLimit, or even setHeap Limit, don't need to a use Process in the method name either, since it's a method of a ChildProcess class. > Source/WebKit2/Shared/unix/ChildProcessMain.h:40 > + virtual void setProcessResourceLimits(); Why is this virtual? Do you think we should provide a way to override the limit at compile time as well? I imagine the address space required could vary considerably depending on the distribution. Something like: #ifndef WEBKIT_CHILD_ADDRESS_SPACE_LIMIT #define WEBKIT_CHILD_ADDRESS_SPACE_LIMIT 5000000000l #endif (In reply to comment #6) > Only resource this limits is memory, no? I would call it setMemoryLimit, or > even setHeap Limit, don't need to a use Process in the method name either, > since it's a method of a ChildProcess class. Let's call it setAddressSpaceLimit. I wish something as simple as a "memory" limit was possible in Linux. (In reply to comment #6) > > Source/WebKit2/Shared/unix/ChildProcessMain.h:40 > > + virtual void setProcessResourceLimits(); > > Why is this virtual? Since all the other member functions of ChildProcessMain are virtual, to allow child processes to have different resource limits. We could leave it non-virtual until a child process wants to do this; I don't care. (In reply to comment #5) > Good idea. An environment variable sounds best. Do you prefer something > short like WEBKIT_CHILD_RLIMIT_AS or WEBKIT_CHILD_ASLIMIT, or something more > descriptive like WEBKIT_CHILD_ADDRESS_SPACE_LIMIT? If set to 0 the limit > would be disabled, otherwise it would be applied in bytes. I like more the first one, but also the others are fine. Created attachment 256616 [details]
Patch
Hi ! i built this map using javascript, dom, svg and external http resources: http://assets-carte.lefigaro.fr/cartes/common/france-resultats-2014.jpg it was a ~4GB memory usage and the only engine that didn't crash or hang or error out or leak like crazy was webkitgtk... While the rationale is certainly good, this limit sounds a bit like shooting oneself in the foot, it should be documented upfront ! Not sure I understand the problem. My web processes require < 50 MiB to display that image. (In reply to comment #11) > Not sure I understand the problem. My web processes require < 50 MiB to > display that image. The image is a jpg created from a big svg file created by those means. This broke Java. The plugin process needs to be exempt from the limit. Created attachment 257645 [details]
Patch
Comment on attachment 257645 [details] Patch Perhaps predictably in retrospect, this has caused a very significant increase in OOM, and generally made the web process less reliable. I'm going to keep the patch in Fedora until the bug in comment #0 is resolved, due to the severity of that bug, but I don't recommend it this for upstream and have removed r? |