If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Anchor links trigger ASSERTION: cannot set pref from content process

RESOLVED DUPLICATE of bug 576511

Status

()

Toolkit
Places
RESOLVED DUPLICATE of bug 576511
6 years ago
7 months ago

People

(Reporter: Martijn Wargers (dead), Unassigned)

Tracking

({assertion, testcase})

Trunk
x86
Windows 7
assertion, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 553460 [details]
testcase

See testcase, when tapping on the link in the testcase, I see this assertion in a debug build:
###!!! ASSERTION: cannot set pref from content process: 'Error', file c:/mozilla
-build/fennec_trunk2/modules/libpref/src/nsPrefBranch.cpp, line 436

Comment 1

6 years ago
This is coming from nsNavHistory, I believe, which gets created, then the init function calls LoadPrefs which attempts to use clearUserPref, and then fails when trying to get the profile dir. Since it failed, it is created again from scratch the next time.
(Reporter)

Comment 2

6 years ago
Yeah, I just caught a stack:
 	KernelBase.dll!75e83e2e() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for KernelBase.dll]	
 	xul.dll!RealBreak()  Line 422	C++
 	xul.dll!Break(const char * aMsg=0x0024b9f0)  Line 521	C++
 	xul.dll!NS_DebugBreak_P(unsigned int aSeverity=1, const char * aStr=0x56c8fe4c, const char * aExpr=0x56c8fe44, const char * aFile=0x56c8fe00, int aLine=436)  Line 380 + 0xc bytes	C++
 	xul.dll!nsPrefBranch::ClearUserPref(const char * aPrefName=0x57448f9c)  Line 436 + 0x1b bytes	C++
 	xul.dll!mozilla::Preferences::ClearUserPref(const char * aPrefName=0x57448f9c)  Line 77 + 0x1a bytes	C++
>	xul.dll!nsNavHistory::LoadPrefs()  Line 1934	C++
 	xul.dll!nsNavHistory::Init()  Line 427	C++
 	xul.dll!nsNavHistory::GetSingleton()  Line 371 + 0x87 bytes	C++
 	xul.dll!nsNavHistoryConstructor(nsISupports * aOuter=0x00000000, const nsID & aIID={...}, void * * aResult=0x0024c044)  Line 16 + 0x26 bytes	C++
 	xul.dll!mozilla::GenericFactory::CreateInstance(nsISupports * aOuter=0x00000000, const nsID & aIID={...}, void * * aResult=0x0024c044)  Line 48 + 0x14 bytes	C++
 	xul.dll!nsComponentManagerImpl::CreateInstanceByContractID(const char * aContractID=0x574385b8, nsISupports * aDelegate=0x00000000, const nsID & aIID={...}, void * * aResult=0x0024c044)  Line 1297 + 0x25 bytes	C++
 	xul.dll!nsComponentManagerImpl::GetServiceByContractID(const char * aContractID=0x574385b8, const nsID & aIID={...}, void * * result=0x0024c09c)  Line 1699 + 0x34 bytes	C++
 	xul.dll!CallGetService(const char * aContractID=0x574385b8, const nsID & aIID={...}, void * * aResult=0x0024c09c)  Line 95	C++
 	xul.dll!nsGetServiceByContractID::operator()(const nsID & aIID={...}, void * * aInstancePtr=0x0024c09c)  Line 278 + 0x13 bytes	C++
 	xul.dll!nsCOMPtr<nsINavHistoryService>::assign_from_gs_contractid(nsGetServiceByContractID gs={...}, const nsID & aIID={...})  Line 1252 + 0xf bytes	C++
 	xul.dll!nsCOMPtr<nsINavHistoryService>::nsCOMPtr<nsINavHistoryService>(nsGetServiceByContractID gs={...})  Line 628	C++
 	xul.dll!nsNavHistory::GetHistoryService()  Line 219	C++
 	xul.dll!nsFaviconService::Init()  Line 144 + 0x5 bytes	C++
 	xul.dll!nsFaviconService::GetSingleton()  Line 109 + 0x87 bytes	C++
 	xul.dll!nsFaviconServiceConstructor(nsISupports * aOuter=0x00000000, const nsID & aIID={...}, void * * aResult=0x0024c1c4)  Line 22 + 0x26 bytes	C++
 	xul.dll!mozilla::GenericFactory::CreateInstance(nsISupports * aOuter=0x00000000, const nsID & aIID={...}, void * * aResult=0x0024c1c4)  Line 48 + 0x14 bytes	C++
 	xul.dll!nsComponentManagerImpl::CreateInstanceByContractID(const char * aContractID=0x572f49d8, nsISupports * aDelegate=0x00000000, const nsID & aIID={...}, void * * aResult=0x0024c1c4)  Line 1297 + 0x25 bytes	C++
 	xul.dll!nsComponentManagerImpl::GetServiceByContractID(const char * aContractID=0x572f49d8, const nsID & aIID={...}, void * * result=0x0024c21c)  Line 1699 + 0x34 bytes	C++
 	xul.dll!CallGetService(const char * aContractID=0x572f49d8, const nsID & aIID={...}, void * * aResult=0x0024c21c)  Line 95	C++
 	xul.dll!nsGetServiceByContractID::operator()(const nsID & aIID={...}, void * * aInstancePtr=0x0024c21c)  Line 278 + 0x13 bytes	C++
 	xul.dll!nsCOMPtr<mozIAsyncFavicons>::assign_from_gs_contractid(nsGetServiceByContractID gs={...}, const nsID & aIID={...})  Line 1252 + 0xf bytes	C++
 	xul.dll!nsCOMPtr<mozIAsyncFavicons>::nsCOMPtr<mozIAsyncFavicons>(nsGetServiceByContractID gs={...})  Line 628	C++
 	xul.dll!`anonymous namespace'::CopyFavicon(nsIURI * aOldURI=0x032f2220, nsIURI * aNewURI=0x0317d4b0)  Line 7993	C++
 	xul.dll!nsDocShell::InternalLoad(nsIURI * aURI=0x0317d4b0, nsIURI * aReferrer=0x032f2050, nsISupports * aOwner=0x0313a930, unsigned int aFlags=0, const wchar_t * aWindowTarget=0x0024c940, const char * aTypeHint=0x0024c760, nsIInputStream * aPostData=0x00000000, nsIInputStream * aHeadersData=0x00000000, unsigned int aLoadType=2097153, nsISHEntry * aSHEntry=0x00000000, int aFirstParty=1, nsIDocShell * * aDocShell=0x00000000, nsIRequest * * aRequest=0x00000000)  Line 8602 + 0x15 bytes	C++
 	xul.dll!nsDocShell::OnLinkClickSync(nsIContent * aContent=0x03100380, nsIURI * aURI=0x0317d4b0, const wchar_t * aTargetSpec=0x048d2318, nsIInputStream * aPostDataStream=0x00000000, nsIInputStream * aHeadersDataStream=0x00000000, nsIDocShell * * aDocShell=0x00000000, nsIRequest etc...
Component: General → IPC
Product: Fennec → Core
QA Contact: general → ipc
(Reporter)

Comment 3

6 years ago
Dan, did you already file a bug for this? (I saw your comment in bug 506269, comment 45)
Does this code really need to clear prefs?
Component: IPC → Places
Product: Core → Toolkit
QA Contact: ipc → places
(In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> Does this code really need to clear prefs?

it is done in a couple cases:
- when we upgrade from 3.6,  we read an old pref and convert it to the new one
- when a database was found corrupt during a previous run, we clear the corrupt pref and replace the database

btw, what do we need to init Places in the content process for? this specific request looks like coming from CopyFavicon in docshell, that has been added recently for session history iirc. it should probably send message to the main process.

Comment 6

6 years ago
Dup of bug 576511?
(Reporter)

Updated

7 months ago
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Updated

7 months ago
Status: REOPENED → RESOLVED
Last Resolved: 7 months ago7 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 576511
You need to log in before you can comment on or make changes to this bug.