[Webkit-unassigned] [Bug 183329] [GTK] 2.19 triggers Gigacage crash in Deja Dup

[bugzilla-daemon at webkit.org]

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

--- Comment #7 from Yusuke Suzuki <utatane.tea at gmail.com> ---
(In reply to Yusuke Suzuki from comment #6)
> (In reply to Michael Catanzaro from comment #4)
> > Jeremy, here's some debug you could try adding to
> > Source/bmalloc/bmalloc/VMAllocate.h:
> > 
> > // At the top of the file, before the bmalloc namespace
> > #include <cstring>
> > #include <errno.h>
> > 
> > inline void* tryVMAllocate(size_t vmSize)
> > {
> >     vmValidate(vmSize);
> >     void* result = mmap(0, vmSize, PROT_READ | PROT_WRITE, MAP_PRIVATE |
> > MAP_ANON | BMALLOC_NORESERVE, BMALLOC_VM_TAG, 0);
> >     if (result == MAP_FAILED)
> > {
> > WTFLogAlways("%s: mmap failed: %d (%s)", __FUNCTION__, errno,
> > strerror(errno));
> >         return nullptr;
> > }
> >     return result;
> > }
> > 
> > That would tell us which of the many possible errors are occurring here.
> > 
> > And if you need an immediate workaround, you can of course build with
> > -DUSE_SYSTEM_MALLOC=ON. That will be bad, so I can't recommend that... but
> > you're already disabling GStreamerGL and web fonts.... :P
> 
> The immediate fix is disabling Gigacage by setting GIGACAGE_ENABLED 0 in
> bmalloc/Gigacage.h.
> This keeps bmalloc, but disables Gigacage.
> 
> My guess is that Linux fails to mmap regions and returns MAP_FAILED if the
> size is very large.
> But I'm not sure right now since it is working on my environment...
> Anyway, @mcatanzaro, do you know the way to allocate virtual memory region
> which does not have actual backing pages?

My guess is that mmap with READ/WRITE starts populating backing pages and it fails.
I think we potentially have two ways to fix this issue.

The first way is,
1. first allocate region with mmap NO_PROTO
2. set read/write if necessary

But since Darwin is not requiring this mechanism, I think we need to change the current code a bit.
For example, vmAllocate() assumes that returned memory is accessible. But this assumption is slightly broken in Linux if we take this way. We need a bit additional code for Linux.

The second way is
1. first allocate region with mmap NO_PROTO
2. deallocate backing pages
3. set read/write for this region immediately

I'm not sure it works. But if it works, the change should be minimum.

-- 
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/20180305/257a26d9/attachment.html>