825976 - crash in libxul.so!PL_DHashTableOperate

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect, P1)

Description

[Michael Vines [:m1] [:evilmachines]]

Attachment: decoded minidump of crash

Test Steps:
1. Run MO call test script.
2. After few hours of run, mini dumps are generated in the phone.

Seen multiple times during run.

Fill minidump decode attached, but here's the top couple frames for easy reference:
Thread 0 (crashed)
 0  libxul.so!PL_DHashTableOperate [pldhash.cpp : 577 + 0x0]
     r4 = 0xbe9736e8    r5 = 0x00000001    r6 = 0xbe973594    r7 = 0x00000017
     r8 = 0x41a147a0    r9 = 0xbe9736e8   r10 = 0xffffffff    fp = 0x00000000
     sp = 0xbe973570    lr = 0x40c35b1b    pc = 0x411550e8
    Found by: given as instruction pointer in context
 1  libxul.so!nsBaseHashtable<nsCStringHashKey, nsCString, nsCString>::Put [nsTHashtable.h : 184 + 0x9]
     r4 = 0xbe9736e8    r5 = 0x00000001    r6 = 0xbe973594    r7 = 0x00000017
     r8 = 0x41a147a0    r9 = 0xbe9736e8   r10 = 0xffffffff    fp = 0x00000000
     sp = 0xbe973588    pc = 0x40c35b1b
    Found by: call frame info
 2  libxul.so!mozilla::dom::CrashReporterParent::AnnotateCrashReport [CrashReporterParent.cpp : 47 + 0x9]
     r4 = 0xbe9735bc    r5 = 0xbe9736e8    r6 = 0x00000017    r7 = 0xbe97367c
     r8 = 0x41a147a0    r9 = 0xbe9736e8   r10 = 0xffffffff    fp = 0x00000000
     sp = 0xbe9735b8    pc = 0x41073e9f
    Found by: call frame info
 3  libxul.so!mozilla::dom::ContentParent::ActorDestroy [ContentParent.cpp : 716 + 0x9]
     r4 = 0x49004160    r5 = 0x48dff760    r6 = 0x00000000    r7 = 0xbe97367c
     r8 = 0x41a147a0    r9 = 0xbe9736e8   r10 = 0xffffffff    fp = 0x00000000
     sp = 0xbe9735d8    pc = 0x41071913
    Found by: call frame info

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Patch that artificially triggers this crash

Fix is trivial, coming right up.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Only use the crash reporter actor if it was successfully created

Comment 3

[(not currently active) Ted Mielczarek]

Comment on attachment 697310 [details] [diff] [review]
Only use the crash reporter actor if it was successfully created

Review of attachment 697310 [details] [diff] [review]:
-----------------------------------------------------------------

What's the failure mode look like here, just "child crashed without leaving a dump"?

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

My best guess is that we're launching a subprocess while under severe memory pressure and it's being lowmemkilled (SIGKILL) before it finishes the crash reporter init.  If so, then yeah we would get a "crash" without a dump.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b33bd9f6bd69

Comment 6

[JP Rosevear [:jpr]]

Can bug 823474 be duped to here?

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Bug 823474 ostensibly covers a different but related problem where plugin-container dies before it initializes IPC.

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(This bug covers the case where plugin-container dies after IPC is initialized, but before the crash reporter is initialized.)

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/b33bd9f6bd69

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/23782346ddb8
https://hg.mozilla.org/releases/mozilla-b2g18/rev/d01d5ed8f667