Looking at the crash dump from https://treeherder.mozilla.org/#/jobs?repo=try&author=mhowell%40mozilla.com&selectedJob=214658342 I see some very weird memory maps. There are many allocations as follows: > 00002e200000 4kB NA MAPPED > 00002e201000 1024kB RW MAPPED > 00002e301000 4kB NA MAPPED Where MAPPED is the Windows VirtualQuery MEM_MAPPED flag. I'm not 100% sure what the 1024 kB blocks are, but my best guess is they are jemalloc arena_chunk_t which require 1 MB alignment for correctness. The patch I see here (https://hg.mozilla.org/try/rev/cc75dcc7e1e37c0680606181ad71e65dc8c09322) doesn't assert alignment after calling |chunk_apply_guards|.
Bug 1446040 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(Jan asked me to take a look since I've studied our allocation behaviors around SpiderMonkey GC and jemalloc in the context of crash analysis). Looking at the crash dump from https://treeherder.mozilla.org/#/jobs?repo=try&author=mhowell%40mozilla.com&selectedJob=214658342 I see some very weird memory maps. There are many allocations as follows: > 00002e200000 4kB NA MAPPED > 00002e201000 1024kB RW MAPPED > 00002e301000 4kB NA MAPPED Where MAPPED is the Windows VirtualQuery MEM_MAPPED flag. I'm not 100% sure what the 1024 kB blocks are, but my best guess is they are jemalloc arena_chunk_t which require 1 MB alignment for correctness. The patch I see here (https://hg.mozilla.org/try/rev/cc75dcc7e1e37c0680606181ad71e65dc8c09322) doesn't assert alignment after calling |chunk_apply_guards|. While the SpiderMonkey GC largely maintains it's own data structures, it still uses jemalloc for some key data structures (eg. StoreBuffer) and jemalloc problems could easily manifest as GC asserts.