Hang at startup: infinite loop starting at nsScriptSecurityManager::Init()

NEW
Assigned to

Status

()

Core
Security: CAPS
--
critical
13 years ago
7 years ago

People

(Reporter: F.J. Olthuis, Assigned: dveditz)

Tracking

({hang})

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: has patch)

Attachments

(1 obsolete attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: Mozilla 1.7

(This bug may be related to bug 213796)

We use Mozilla 1.7, embedded in a Visual C++ application.

At some point our user_prefs contained the following lines:

user_pref
("capability.principal.codebaseTrusted.myprincipal1.granted", "UniversalXPConne
ct");
user_pref
("capability.principal.codebaseTrusted.myprincipal1.id", "myprotocol://develop.
mycompany.com:1234");
user_pref
("capability.principal.codebaseTrusted.myprincipal2.granted", "UniversalXPConne
ct");
user_pref
("capability.principal.codebaseTrusted.myprincipal2.id", "myprotocol://develop.
mycompany.com:1234");


With these user_prefs, when nsScriptSecurityManager is created, the following 
call stack is produced, which contains a loop (an infinite one):

>	caps.dll!nsScriptSecurityManager::Init()  Line 2637	C++
 	caps.dll!nsScriptSecurityManager::GetScriptSecurityManager()  Line 
2711 + 0x8	C++
 	caps.dll!nsPrincipal::Equals(nsIPrincipal * aOther=0x01f89368, int * 
aResult=0x0140eb24)  Line 243 + 0x5	C++
 	caps.dll!PrincipalKey::KeyEquals(const nsIPrincipal * 
aKey=0x01f89368)  Line 123	C++
 	caps.dll!
nsTHashtable<nsBaseHashtableET<PrincipalKey,nsCOMPtr<nsIPrincipal> > 
>::s_MatchEntry(PLDHashTable * table=0x01f69d54, const PLDHashEntryHdr * 
entry=0x01f69e8c, const void * key=0x01f89368)  Line 382	C++
 	xpcom.dll!SearchTable(PLDHashTable * table=0x01f69d54, const void * 
key=0x01f89368, unsigned int keyHash=0x8f053d64, PLDHashOperator 
op=PL_DHASH_ADD)  Line 378 + 0x1c	C
 	xpcom.dll!PL_DHashTableOperate(PLDHashTable * table=0x01f69d54, const 
void * key=0x01f89368, PLDHashOperator op=PL_DHASH_ADD)  Line 535 + 0x15
	C
 	caps.dll!
nsTHashtable<nsBaseHashtableET<PrincipalKey,nsCOMPtr<nsIPrincipal> > 
>::PutEntry(const nsIPrincipal * aKey=0x01f89368)  Line 181 + 0x18	C++
 	caps.dll!
nsBaseHashtable<PrincipalKey,nsCOMPtr<nsIPrincipal>,nsIPrincipal *>::Put(const 
nsIPrincipal * aKey=0x01f89368, nsIPrincipal * aData=0x01f89368)  Line 146 + 
0xc	C++
 	caps.dll!nsScriptSecurityManager::InitPrincipals(unsigned int 
aPrefCount=0x00000006, const char * * aPrefNames=0x01f83008, nsISecurityPref * 
aSecurityPref=0x01f07234)  Line 3146	C++
 	caps.dll!nsScriptSecurityManager::InitPrefs()  Line 3209 + 0x1c	C++
 	caps.dll!nsScriptSecurityManager::Init()  Line 2645 + 0x8	C++
 	caps.dll!nsScriptSecurityManager::GetScriptSecurityManager()  Line 
2711 + 0x8	C++
 	caps.dll!Construct_nsIScriptSecurityManager(nsISupports * 
aOuter=0x00000000, const nsID & aIID={...}, void * * aResult=0x0140ee5c)  Line 
330 + 0x5	C++
 


Reproducible: Always
Steps to Reproduce:
1.
2.
3.




caps.dll

Comment 1

13 years ago
Created attachment 166083 [details] [diff] [review]
thought

reporter: what happens if you run with this?

Comment 2

13 years ago
nm, the answer of course is that we crash in the place where we currently
infinitely recurse. i believe this is a regression from bug 220421. but i'm not
in a position to prove that (i'm going to sleep).

brendan: that would make it your bug :)
Assignee: dveditz → brendan
Depends on: 220421
Keywords: crash
(Reporter)

Comment 3

13 years ago
I'm having some trouble testing this, but it seems to me a cleaner solution is 
to add the following line to the nsScriptSecurityManager constructor:
	gScriptSecMan = this;

and remove from nsScriptSecurityManager::Init() :
	gScriptSecMan = ssManager;

Timeless: stop reassigning bugs to me based on misdiagnoses of old bugs.  My
patches in bug 220421 didn't change anything to do with this, and if even older
fastload changes of mine (or anyone else's) did change security manager init in
a way that broke this, that's regrettable, but I think we should all want
caillon to field this one.

/be
Assignee: brendan → caillon
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

13 years ago
brendan: it absolutely did. before your change the securitycompareuri method was
staic and didn't need an instance. after your change, the method required an
instance and led directly to this infinite recursion.
Timeless: great, but I'm still very sure that caillon wants dibs.

/be

Comment 7

11 years ago
timeless - should patch attachment (id=166083) [edit]  incorporate comment 3?  

reporter is gone - support at oclcpica.org writes "we are no longer interesested in these bugs, since it is such a long time ago. But thanks annyway. Yours sincerely, Servicedesk"

changing to modern default assignee and QA
Whiteboard: has patch

Comment 8

11 years ago
see comment 7
changing to modern default assignee and QA for real
Assignee: caillon → dveditz
QA Contact: caps
Keywords: crash → hang
Summary: Crash at startup: infinite loop starting at nsScriptSecurityManager::Init() → Hang at startup: infinite loop starting at nsScriptSecurityManager::Init()

Updated

8 years ago
Attachment #166083 - Attachment is obsolete: true
Attachment #166083 - Flags: review-

Comment 9

7 years ago
caillon, I was unable to find hang reports in crash-stats. 
There are however a few crashes. filed as Bug 622518 - startup crash [@ nsScriptSecurityManager::Init()
OS: Windows XP → All
You need to log in before you can comment on or make changes to this bug.