#16898: WebKit rebased consistently crashes on Amazon.ca [WASM memory allocation
error]
---------------------------+-------------------------
Reporter: vidrep | Owner: pulkomandy
Type: bug | Status: new
Priority: normal | Milestone: Unscheduled
Component: Kits/Web Kit | Version: R1/beta2
Resolution: | Keywords:
Blocked By: | Blocking: 16957
Platform: x86-64 |
---------------------------+-------------------------
Comment (by pulkomandy):
The crash here is not in malloc code. It's in webkit directly calling mmap
to manage its own memory. So, no, this isn't related.
There is a known problem with the hoard2 allocator that it is based on a
single memory area that we currently size at about 2GB. Whenever an
application tries to malloc more than that, it doesn't work. We need to
replace the memory allocator, but so far we have not found one that
handles our use case well, especially on 32bit systems. Modern allocators
tend to require a lot of address space there, and they also create a lot
of smaller areas, when we would prefer a single larger one. But WebKit
isn't subject to this, at least in this case.
If you want to investigate this, you rather need to look at the mprotect
implementation and see why it is failing.
Here is the failing syscall:
{{{
[ 2411] set_memory_protection(0xc60265e000, 0xff800000, 0x0) = 0x80000000
Out of memory (2 us)
}}}
I think the area this is operating on is this one, created just before:
{{{
[ 2411] map_file("libWebKitLegacy.so.1 mmap area", 0x7fb77fd2fe48, 0x6,
0x100800000, 0x3, 0x1, true, 0x0, 0xffffffff) = 0x486e (6 us)
}}}
It's a bit hard to be sure, because map_file returns an area_id, but
doesn't say the address it mapped the area at. The set_memory_protection
has a smaller size than the area, that corresponds to the "initialBytes"
offset in the mprotect calls that I linked in an earlier comment.
The size of the memory part it's trying to unmap is quite large (about
4GB) but on a 64bit system I think this should not be a problem? The
initial size of the area is also more than 4GB.
So, it should not be too hard to write a similar test case now that we
have the sequence of operations:
1) call mmap to create a large area (size: 0x100800000, that's 4GiB +
8MiB)
2) call mprotect to unmap most of that area, keeping 16MiB allocated at
the start
Confirm with strace that you get the same parameters as in the trace we
have here (addresses and area IDs will be different, but try to get the
flags as identical as possible).
Then we will have something that's a lot easier to investigate on.
Hopefully it reproduces the problem.
--
Ticket URL: <https://dev.haiku-os.org/ticket/16898#comment:21>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
