Closed
Bug 576511
Opened 14 years ago
Closed 7 years ago
e10s: Assertion in nsPrefBranch::ClearUserPref while loading page
Categories
(Core :: DOM: Content Processes, defect)
Tracking
()
RESOLVED
INVALID
Tracking | Status | |
---|---|---|
e10s | later | --- |
People
(Reporter: starkov.egor, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.19) Gecko/2010031218 Firefox/3.5 Build Identifier: When loading http://bash.org.ru/rss get this assertion: ###!!! ASSERTION: cannot set pref from content process: 'Error', file /home/egor/harmattan_hg1/microb-engine/build-tree/mozilla/modules/libpref/src/nsPrefBranch.cpp, line 539 Here's the stack trace: #0 nsPrefBranch::ClearUserPref (this=0xb152ba60, aPrefName=0xb7333a81 "browser.history_expire_days") at mozilla/modules/libpref/src/nsPrefBranch.cpp:538 #1 0xb5b069d8 in nsPrefService::ClearUserPref (this=0xb152ba30, aPrefName=0xb7333a81 "browser.history_expire_days") at mozilla/modules/libpref/src/nsPrefService.h:60 #2 0xb6bc8f84 in nsNavHistory::LoadPrefs (this=0xac7a2e00) at mozilla/toolkit/components/places/src/nsNavHistory.cpp:2088 #3 0xb6becfb1 in nsNavHistory::Init (this=0xac7a2e00) at mozilla/toolkit/components/places/src/nsNavHistory.cpp:433 #4 0xb6bed6b2 in nsNavHistory::GetSingleton () at mozilla/toolkit/components/places/src/nsNavHistory.cpp:381 #5 0xb6c34fc5 in nsNavHistoryConstructor (aOuter=0x0, aIID=..., aResult=0xbf825620) at mozilla/toolkit/components/places/src/nsPlacesModule.cpp:22 #6 0xb6eb0962 in nsGenericFactory::CreateInstance (this=0xaf882f80, aOuter=0x0, aIID=..., aResult=0xbf825620) at nsGenericFactory.cpp:80 #7 0xb6f16cac in nsComponentManagerImpl::CreateInstanceByContractID (this=0xb1555100, aContractID=0xb72e5548 "@mozilla.org/browser/download-history;1", aDelegate=0x0, aIID=..., aResult=0xbf825620) at mozilla/xpcom/components/nsComponentManager.cpp:1725 #8 0xb6f12163 in nsComponentManagerImpl::GetServiceByContractID (this=0xb1555100, aContractID=0xb72e5548 "@mozilla.org/browser/download-history;1", aIID=..., result=0xbf825840) at mozilla/xpcom/components/nsComponentManager.cpp:2310 Why can't child process set preferences and how can this assertion be fixed? Reproducible: Always
Reporter | ||
Updated•14 years ago
|
Summary: e10s: Assertion win nsPrefBranch::ClearUserPref while loading page → e10s: Assertion in nsPrefBranch::ClearUserPref while loading page
Comment 1•14 years ago
|
||
> Why can't child process set preferences Because preferences are managed by the chrome process. How would children be able to set them without racing, exactly? > how can this assertion be fixed? In this case, by having the download history or nav history ctors fail out in the content process, I'd think. No idea what that would do for code higher up the stack, obviously.
Comment 2•14 years ago
|
||
I'm using latest m-c 47782:b141a304ad08, + bug_551181_notify_chrome_about_visit_page bug_516728_link_visited 568925_title_uri.diff And have this backtrace: #0 nsPrefBranch::ClearUserPref (this=0xb1574280, aPrefName=0xb73dd7a6 "browser.history_expire_days") at modules/libpref/src/nsPrefBranch.cpp:539 #1 0xb5b17fc9 in nsPrefService::ClearUserPref (this=0xb1574250, aPrefName=0xb73dd7a6 "browser.history_expire_days") at modules/libpref/src/nsPrefService.h:60 #2 0xb6a515d5 in nsNavHistory::LoadPrefs (this=0xb212c800) at toolkit/components/places/src/nsNavHistory.cpp:2080 #3 0xb6a448a8 in nsNavHistory::Init (this=0xb212c800) ---Type <return> to continue, or q <return> to quit--- at toolkit/components/places/src/nsNavHistory.cpp:414 #4 0xb6a436c2 in nsNavHistory::GetSingleton () at toolkit/components/places/src/nsNavHistory.cpp:362 #5 0xb6ab2df2 in nsNavHistoryConstructor (aOuter=0x0, aIID=@0xb736a6f4, aResult=0xbf953958) at toolkit/components/places/src/nsPlacesModule.cpp:15 #6 0xb6d19d0c in mozilla::GenericFactory::CreateInstance (this=0xb00e6980, aOuter=0x0, aIID=@0xb736a6f4, aResult=0xbf953958) at GenericFactory.cpp:48 ---Type <return> to continue, or q <return> to quit--- #7 0xb6d782ad in nsComponentManagerImpl::CreateInstanceByContractID (this=0xb2145300, aContractID=0xb7367be8 "@mozilla.org/browser/global-history;2", aDelegate=0x0, aIID=@0xb736a6f4, aResult=0xbf953958) at xpcom/components/nsComponentManager.cpp:1308 #8 0xb6d78f26 in nsComponentManagerImpl::GetServiceByContractID (this=0xb2145300, aContractID=0xb7367be8 "@mozilla.org/browser/global-history;2", aIID=@0xb736a6f4, result=0xbf953a4c) at xpcom/components/nsComponentManager.cpp:1670 #9 0xb6d0a522 in CallGetService (aContractID=0xb7367be8 "@mozilla.org/browser/global-history;2", aIID=@0xb736a6f4, aResult=0xbf953a4c) at nsComponentManagerUtils.cpp:94 ---Type <return> to continue, or q <return> to quit--- #10 0xb6d0aa56 in nsGetServiceByContractIDWithError::operator() (this=0xbf953a98, aIID=@0xb736a6f4, aInstancePtr=0xbf953a4c) at nsComponentManagerUtils.cpp:288 #11 0xb67f6744 in nsCOMPtr<nsIGlobalHistory2>::assign_from_gs_contractid_with_error (this=0xaf523300, gs=@0xbf953a98, aIID=@0xb736a6f4) at ../../dist/include/nsCOMPtr.h:1262 #12 0xb67f463a in nsCOMPtr<nsIGlobalHistory2>::operator= (this=0xaf523300, rhs=@0xbf953a98) at ../../dist/include/nsCOMPtr.h:721 #13 0xb67d42c4 in nsDocShell::SetUseGlobalHistory (this=0xaf523190, aUseGlobalHistory=1) at docshell/base/nsDocShell.cpp:3385 #14 0xb68749b9 in nsWebBrowser::EnableGlobalHistory (this=0xb00e71c0, aEnable=1) ---Type <return> to continue, or q <return> to quit--- at embedding/browser/webBrowser/nsWebBrowser.cpp:363 #15 0xb6878575 in nsWebBrowser::Create (this=0xb00e71c0) at embedding/browser/webBrowser/nsWebBrowser.cpp:1217 #16 0xb6b891e6 in mozilla::dom::TabChild::RecvCreateWidget (this=0xb00e0200, parentWidget=@0xbf953e54) at dom/ipc/TabChild.cpp:453 #17 0xb6c97fe2 in mozilla::dom::PBrowserChild::OnMessageReceived (this=0xb00e0200, __msg=@0xbf9540bc) at PBrowserChild.cpp:748 #18 0xb6ca25e3 in mozilla::dom::PContentChild::OnMessageReceived (this=0xb2138038, __msg=@0xbf9540bc) ---Type <return> to continue, or q <return> to quit--- at PContentChild.cpp:694
Comment 3•14 years ago
|
||
We're not supposed to be creating nsNavHistory in the content process, right? So then I guess the question is, what are we supposed to do for nsIGlobalHistory2?
Comment 4•14 years ago
|
||
> We're not supposed to be creating nsNavHistory in the content process, right? That's what I think, yes. > what are we supposed to do for nsIGlobalHistory2? What do we do for IHistory? I'd think we should do the same...
Comment 5•14 years ago
|
||
(In reply to comment #3) > We're not supposed to be creating nsNavHistory in the content process, right? I think so. > So then I guess the question is, what are we supposed to do for > nsIGlobalHistory2? I think we create history in parent process and just sending updates to parent process.... probably that is related to 516728, 551181,
Comment 6•14 years ago
|
||
(In reply to comment #4) > What do we do for IHistory? I'd think we should do the same... IHistory forwards to the parent process in the content process (I think that code landed at least...still catching up)
Updated•10 years ago
|
tracking-e10s:
--- → +
Updated•10 years ago
|
Updated•10 years ago
|
Component: IPC → DOM: Content Processes
Updated•7 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•