This bug was filed from the Socorro interface and is report bp-c004f97b-12f7-40c4-8a2a-4ea092121220 . ============================================================= Top frames: 0 libmozglue.so jemalloc_crash jemalloc.c:1582 1 libmozglue.so arena_dalloc jemalloc.c:3336 2 libmozglue.so free jemalloc.c:6589 3 libxul.so moz_free mozalloc.cpp:48 4 libxul.so nsStringBuffer::Release nsSubstring.cpp:161 5 libxul.so FinalizeDOMString XPCString.cpp:40 6 libxul.so js::gc::FinalizeArenas String-inl.h:451 7 libxul.so IncrementalCollectSlice jsgc.cpp:1660 8 libxul.so GCCycle jsgc.cpp:4540 9 libxul.so js::GCSlice jsgc.cpp:4655 10 libxul.so js::IncrementalGC jsfriendapi.cpp:172 Here's a different installation encountering this crash: bp-12f76cb7-cd7c-44b6-aeb2-4bf862121220

How is this related to bug 721710?

I am not sure why this bug is dependent on bug 721710. However, it does sounds alot like bug 817946. Justin, should we mark this as a dup on that?

(In reply to Brian Smith (:bsmith) from comment #1) > How is this related to bug 721710? Erm, sorry, wrong dependency.

The failing assertion is RELEASE_ASSERT((run->regs_mask[elm] & (1U << bit)) == 0); which is checking that the thing we're freeing corresponds to a live malloc'ed block. So this is likely a double-free or a free of something which was never malloc'ed. I don't think we should dupe to bug 817946 -- that bug is already unwieldy with many likely unrelated issues being discussed, and this bug doesn't have anything to do with libsqlite.so.

(In reply to Justin Lebar [:jlebar] (away 12/21-1/2) from comment #4) > I don't think we should dupe to bug 817946 -- that bug is already unwieldy > with many likely unrelated issues being discussed, and this bug doesn't have > anything to do with libsqlite.so. Bug 817946 prolly needs to just be withdrawn soon. Now that the minidumps are producing much better backtraces I'm seeing very few unhelpful bts that orignally spawned that bug.

Large number of crashes, plus this.

Related to 823955?

We ran into this crash last night while receiving MT calls as missed calls for a couple hours. There was memory pressure at the time of the crash but beyond that nothing too interesting that I see.

This may or may not be bug 822398, but mass-closing so that we can get better resolution on crashes that still reproduce.