Closed Bug 569270 Opened 15 years ago Closed 14 years ago

e10s: Assertion on child process shutdown in xpcshell

Categories

(Core :: IPC, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jdm, Assigned: fred23)

Details

Attachments

(1 file, 2 obsolete files)

(gdb) bt #0 0x00532416 in __kernel_vsyscall () #1 0x005ced96 in nanosleep () from /lib/libc.so.6 #2 0x005cebb1 in sleep () from /lib/libc.so.6 #3 0x00ec2289 in ah_crap_handler (signum=6) at /home/t_mattjo/src/firefox/mobilebase/toolkit/xre/nsSigHandlers.cpp:132 #4 0x00ec22e2 in child_ah_crap_handler (signum=6) at /home/t_mattjo/src/firefox/mobilebase/toolkit/xre/nsSigHandlers.cpp:145 #5 <signal handler called> #6 0x00532416 in __kernel_vsyscall () #7 0x0055da81 in raise () from /lib/libc.so.6 #8 0x0055f34a in abort () from /lib/libc.so.6 #9 0x0047ef84 in mozalloc_abort (msg=0xbfee47cc "###!!! ASSERTION: Content Protocol is NULL!: 'cpc', file /home/t_mattjo/src/firefox/mobilebase/modules/libpref/src/nsPrefBranch.cpp, line 833") at /home/t_mattjo/src/firefox/mobilebase/memory/mozalloc/mozalloc_abort.cpp:73 #10 0x021abad6 in Abort (aMsg=0xbfee47cc "###!!! ASSERTION: Content Protocol is NULL!: 'cpc', file /home/t_mattjo/src/firefox/mobilebase/modules/libpref/src/nsPrefBranch.cpp, line 833") at /home/t_mattjo/src/firefox/mobilebase/xpcom/base/nsDebugImpl.cpp:371 #11 0x021aba99 in NS_DebugBreak_P (aSeverity=1, aStr=0x2547705 "Content Protocol is NULL!", aExpr=0x2547701 "cpc", aFile=0x2547610 "/home/t_mattjo/src/firefox/mobilebase/modules/libpref/src/nsPrefBranch.cpp", aLine=833) at /home/t_mattjo/src/firefox/mobilebase/xpcom/base/nsDebugImpl.cpp:358 #12 0x01039980 in nsPrefBranch::RemoveObserver (this=0xb51ec9c0, aDomain=0x24547df "network.tcp.sendbuffer", aObserver=0xb7522010) at /home/t_mattjo/src/firefox/mobilebase/modules/libpref/src/nsPrefBranch.cpp:833 #13 0x0103ee3c in nsPrefService::RemoveObserver (this=0xb7511a00, aDomain=0x24547df "network.tcp.sendbuffer", aObserver=0xb7522010) at /home/t_mattjo/src/firefox/mobilebase/modules/libpref/src/nsPrefService.h:61 #14 0x00f17177 in nsSocketTransportService::Shutdown (this=0xb7522000) at /home/t_mattjo/src/firefox/mobilebase/netwerk/base/src/nsSocketTransportService2.cpp:475 #15 0x00eed3fd in nsIOService::SetOffline (this=0xb752ad80, offline=1) at /home/t_mattjo/src/firefox/mobilebase/netwerk/base/src/nsIOService.cpp:723 #16 0x00eedeee in nsIOService::Observe (this=0xb752ad80, subject=0xb755f104, topic=0x28126d0 "xpcom-shutdown", data=0x0) at /home/t_mattjo/src/firefox/mobilebase/netwerk/base/src/nsIOService.cpp:933 #17 0x0214efa7 in nsObserverList::NotifyObservers (this=0xb7555dc0, aSubject=0xb755f104, aTopic=0x28126d0 "xpcom-shutdown", someData=0x0) at /home/t_mattjo/src/firefox/mobilebase/xpcom/ds/nsObserverList.cpp:130 #18 0x02150945 in nsObserverService::NotifyObservers (this=0xb7511a30, aSubject=0xb755f104, aTopic=0x28126d0 "xpcom-shutdown", someData=0x0) at /home/t_mattjo/src/firefox/mobilebase/xpcom/ds/nsObserverService.cpp:182 #19 0x02142bda in mozilla::ShutdownXPCOM (servMgr=0x0) at /home/t_mattjo/src/firefox/mobilebase/xpcom/build/nsXPComInit.cpp:795 #20 0x021429df in NS_ShutdownXPCOM_P (servMgr=0x0) at /home/t_mattjo/src/firefox/mobilebase/xpcom/build/nsXPComInit.cpp:758 #21 0x00ec2aae in XRE_TermEmbedding () at /home/t_mattjo/src/firefox/mobilebase/toolkit/xre/nsEmbedFunctions.cpp:242 #22 0x0202d5c3 in mozilla::ipc::ScopedXREEmbed::Stop (this=0xb75341b8) at /home/t_mattjo/src/firefox/mobilebase/ipc/glue/ScopedXREEmbed.cpp:100 #23 0x01ff5c2a in mozilla::dom::ContentProcessProcess::CleanUp (this=0xb7534020) at /home/t_mattjo/src/firefox/mobilebase/dom/ipc/ContentProcessProcess.cpp:63 #24 0x00ec2ffb in XRE_InitChildProcess (aArgc=1, aArgv=0xbfee5b74, aProcess=GeckoProcessType_Content) at /home/t_mattjo/src/firefox/mobilebase/toolkit/xre/nsEmbedFunctions.cpp:451 #25 0x08049050 in main (argc=3, argv=0xbfee5b74) at /home/t_mattjo/src/firefox/mobilebase/ipc/app/MozillaRuntimeMain.cpp:87
So if I understand this trace correctly, some consumer in the content process is trying to remove pref observers (nsPrefBranch::RemoveObserver) AFTER it's been cleaned-up. I guess in that case, nsPrefBranch::RemoveObserver could just silently return without asserting because we already removed every prefObservers from the content process at child destruction. Dan, what do you think?
That sounds fine, with a comment explaining why. The parent doesn't care at all, right?
right, the parent doesn't care. it's just forwarding every pref (listening for "") to the child and doesn't care about actual observer structs. I'll create a patch and submit for review.
Attached patch patch (obsolete) — Splinter Review
patch, according to discussions
Assignee: nobody → bugzillaFred
Attachment #449611 - Flags: review?(dwitte)
>+ rv = cpc->RemoveRemotePrefObserver(nsDependentCString(aDomain), >+ mPrefRoot, >+ aObserver); Line up mPrefRoot and aObserver with nsDependentCString, please.
Attached file patch (obsolete) —
Attached patch patch v.2Splinter Review
(In reply to comment #5) > >+ rv = cpc->RemoveRemotePrefObserver(nsDependentCString(aDomain), > >+ mPrefRoot, > >+ aObserver); > > Line up mPrefRoot and aObserver with nsDependentCString, please. jeez, you're right ! thanks.
Attachment #449611 - Attachment is obsolete: true
Attachment #449638 - Attachment is obsolete: true
Attachment #449640 - Flags: review?(dwitte)
Attachment #449611 - Flags: review?(dwitte)
Comment on attachment 449640 [details] [diff] [review] patch v.2 Looks good. r=dwitte
Attachment #449640 - Flags: review?(dwitte) → review+
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: