203030 - Crashes in Permission Manager

Status: RESOLVED FIXED

(Core :: Graphics: Image Blocking, defect)

Description

[Harshal Pradhan]

My trunk VC7 debug build is crashing a lot in nsPermissionManager. Apparent 
regression from bug 200697.

The stack trace is something like this .......

----------------------------------------------------------------------------
 	cookie.dll!0281005e() 	
>	cookie.dll!nsTHashtable<nsHostEntry>::GetEntry(const char * 
aKey=0x0012f1b8)  Line 276 + 0xf	C++
 	cookie.dll!nsPermissionManager::TestPermission(nsIURI * 
aURI=0x035d08f0, unsigned int aType=1, unsigned int * aPermission=0x0012f22c)  
Line 349 + 0x18	C++
 	cookie.dll!nsImgManager::TestPermission(nsIURI * 
aCurrentURI=0x035d08f0, nsIURI * aFirstURI=0x0358cdf8, int * 
aPermission=0x0012f45c)  Line 248	C++
 	cookie.dll!nsImgManager::ShouldLoad(int aContentType=2, nsIURI * 
aContentLoc=0x035d08f0, nsISupports * aContext=0x035d07d0, nsIDOMWindow * 
aWindow=0x03585774, int * aShouldLoad=0x0012f45c)  Line 170 + 0x21	C++
 	gklayout.dll!nsContentPolicy::CheckPolicy(int policyType=0, int 
contentType=2, nsIURI * contentLocation=0x035d08f0, nsISupports * 
context=0x035d07d0, nsIDOMWindow * window=0x03585774, int * 
shouldProceed=0x0012f45c)  Line 140 + 0x2b	C++
 	gklayout.dll!nsContentPolicy::ShouldLoad(int contentType=2, nsIURI * 
contentLocation=0x035d08f0, nsISupports * context=0x035d07d0, nsIDOMWindow * 
window=0x03585774, int * shouldLoad=0x0012f45c)  Line 167	C++
 	gklayout.dll!NS_CheckContentLoadPolicy(int contentType=2, nsIURI * 
aURI=0x035d08f0, nsISupports * context=0x035d07d0, nsIDOMWindow * 
window=0x03585774, int * shouldLoad=0x0012f45c)  Line 56 + 0x70	C++
 	gklayout.dll!nsImageLoadingContent::CanLoadImage(nsIURI * 
aURI=0x035d08f0, nsIDocument * aDocument=0x03127468)  Line 534 + 0x1c	C++
 	gklayout.dll!nsImageLoadingContent::ImageURIChanged(const nsACString & 
aNewURI={...})  Line 394 + 0x1d	C++
 	gklayout.dll!nsImageLoadingContent::ImageURIChanged(const nsAString & 
aNewURI={...})  Line 348 + 0x16	C++
 	gklayout.dll!nsHTMLImageElement::SetAttr(int aNameSpaceID=0, nsIAtom * 
aName=0x00dc09c8, const nsAString & aValue={...}, int aNotify=0)  Line 620
	C++
 	gklayout.dll!HTMLContentSink::AddAttributes(const nsIParserNode & aNode=
{...}, nsIHTMLContent * aContent=0x035d07b0, int aNotify=0)  Line 911	C++
 	gklayout.dll!SinkContext::AddLeaf(const nsIParserNode & aNode={...})  
Line 1623 + 0x1c	C++
 	gklayout.dll!HTMLContentSink::AddLeaf(const nsIParserNode & aNode=
{...})  Line 3386 + 0x12	C++
 	gkparser.dll!CNavDTD::AddLeaf(const nsIParserNode * aNode=0x035cff18)  
Line 3697 + 0x19	C++
 	gkparser.dll!CNavDTD::HandleDefaultStartToken(CToken * 
aToken=0x0355b530, nsHTMLTag aChildTag=eHTMLTag_img, nsCParserNode * 
aNode=0x035cff18)  Line 1384 + 0xc	C++
 	gkparser.dll!CNavDTD::HandleStartToken(CToken * aToken=0x0355b530)  
Line 1758 + 0x14	C++
 	gkparser.dll!CNavDTD::HandleToken(CToken * aToken=0x0355b530, nsIParser 
* aParser=0x031280c8)  Line 942 + 0xc	C++
 	gkparser.dll!CNavDTD::BuildModel(nsIParser * aParser=0x031280c8, 
nsITokenizer * aTokenizer=0x0309f488, nsITokenObserver * anObserver=0x00000000, 
nsIContentSink * aSink=0x03128300)  Line 511 + 0x14	C++
 	gkparser.dll!nsParser::BuildModel()  Line 1898 + 0x22	C++
 	gkparser.dll!nsParser::ResumeParse(int allowIteration=1, int 
aIsFinalChunk=0, int aCanInterrupt=1)  Line 1765 + 0xc	C++
 	gkparser.dll!nsParser::OnDataAvailable(nsIRequest * request=0x0358d130, 
nsISupports * aContext=0x00000000, nsIInputStream * pIStream=0x0335aed0, 
unsigned int sourceOffset=0, unsigned int aLength=872)  Line 2429 + 0x15
	C++
 	docshell.dll!nsDocumentOpenInfo::OnDataAvailable(nsIRequest * 
request=0x0358d130, nsISupports * aCtxt=0x00000000, nsIInputStream * 
inStr=0x0335aed0, unsigned int sourceOffset=0, unsigned int count=872)  Line 
239 + 0x2e	C++
 	necko.dll!nsStreamListenerTee::OnDataAvailable(nsIRequest * 
request=0x0358d130, nsISupports * context=0x00000000, nsIInputStream * 
input=0x0358e52c, unsigned int offset=0, unsigned int count=872)  Line 97 + 0x33
	C++
 	necko.dll!nsHttpChannel::OnDataAvailable(nsIRequest * 
request=0x0358e760, nsISupports * ctxt=0x00000000, nsIInputStream * 
input=0x0358e52c, unsigned int offset=0, unsigned int count=872)  Line 3174 + 
0x3f	C++
 	necko.dll!nsInputStreamPump::OnStateTransfer()  Line 418 + 0x41	C++
 	necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * 
stream=0x0358e52c)  Line 321 + 0xb	C++
 	xpcom.dll!nsInputStreamReadyEvent::EventHandler(PLEvent * 
plevent=0x0358ed3c)  Line 117	C++
 	xpcom.dll!PL_HandleEvent(PLEvent * self=0x0358ed3c)  Line 659 + 0xa
	C
 	xpcom.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00debb68)  Line 
592 + 0x9	C
 	xpcom.dll!_md_EventReceiverProc(HWND__ * hwnd=0x000f06e6, unsigned int 
uMsg=49390, unsigned int wParam=0, long lParam=14596968)  Line 1395 + 0x9
	C
 	USER32.DLL!77e3a244() 	
 	USER32.DLL!77e145e5() 	
 	USER32.DLL!77e1a792() 	
 	appshell.dll!nsAppShellService::Run()  Line 479	C++
 	mozilla.exe!main1(int argc=1, char * * argv=0x00264ac0, nsISupports * 
nativeApp=0x00defd18)  Line 1268 + 0x20	C++
 	mozilla.exe!main(int argc=1, char * * argv=0x00264ac0)  Line 1647 + 0x25
	C++
 	mozilla.exe!mainCRTStartup()  Line 400 + 0x11	C
 	KERNEL32.DLL!77ea847c() 	

----------------------------------------------------------------------------

Comment 1

[Harshal Pradhan]

This is where it blows up in pldhash.c.

xpcom.dll!PL_DHashTableOperate(PLDHashTable * table=0x014ee4ec, const void * 
key=0x0012f1b8, PLDHashOperator op=PL_DHASH_LOOKUP)  Line 469	C
cookie.dll!nsTHashtable<nsHostEntry>::GetEntry(const char * aKey=0x0012f1b8)  
Line 276 + 0xf	C++

Basically calling |table->ops->hashKey(table, key)| blows things up. Looks like 
ops->hashKey points to something invalid.

----------------------------------------------------------------------------

Here is a dump of ops

-	ops	0x02833c2c struct PLDHashTableOps nsTHashtable<class 
nsHostEntry>::sOps	const PLDHashTableOps *
	allocTable	0x0282b6b2 PL_DHashAllocTable	void * (PLDHashTable *, 
unsigned int)*
	freeTable	0x0282b6ac PL_DHashFreeTable	void (PLDHashTable *, 
void *)*
	getKey	        0x0281005e	const void * (PLDHashTable *, 
PLDHashEntryHdr *)*
	hashKey	        0x0281005e	unsigned int (PLDHashTable *, const 
void *)*
	matchEntry	0x0281005e	int (PLDHashTable *, const 
PLDHashEntryHdr *, const void *)*
	moveEntry	0x0282b6a6 PL_DHashMoveEntryStub	void 
(PLDHashTable *, const PLDHashEntryHdr *, PLDHashEntryHdr *)*
	clearEntry	0x0281151e nsTHashtable<class nsHostEntry>::s_ClearEntry
(struct PLDHashTable *,struct PLDHashEntryHdr *)	void (PLDHashTable *, 
PLDHashEntryHdr *)*
	finalize	0x0282b6a0 PL_DHashFinalizeStub	void (PLDHashTable *)*
	initEntry	0x0281155f nsTHashtable<class nsHostEntry>::s_InitEntry
(struct PLDHashTable *,struct PLDHashEntryHdr *,void const *)	void 
(PLDHashTable *, PLDHashEntryHdr *, const void *)*



Seems wierd to me that getKey, hashKey and matchEntry are all the same.

Comment 2

[[e-mail]]

hmmm, this smells like some really weird problem in nsTHash.

-> bsmedberg for now - any idea what could be going wrong here? this is a
win32-only problem! really strange.

this will most likely be a smoketest blocker on win32 in a few hours' time, so
if we could get a handle on this RSN that'd save some grief...

Comment 3

[Harshal Pradhan]

cc'ing some hashtable people.

Comment 4

[Harshal Pradhan]

Attachment: Hack!

This works around the crash... and its managed to totally confuse me.

This is looking very much like a compiler issue, and may infact be specific to
VC7.

The reason I tried this in the first place was that. I couldnt figure out why
clearEntry and initEntry seemed to have valid values but get/match/move didnt.
So i forced calling AllowMemMove() before those three are initialized. And sure
enough, it works.

After this ops looks like this ....

-	ops	0x01223c2c struct PLDHashTableOps nsTHashtable<class
nsHostEntry>::sOps const PLDHashTableOps *
	allocTable	0x0121b7b8 PL_DHashAllocTable	void * (PLDHashTable *,
unsigned int)*
	freeTable	0x0121b7b2 PL_DHashFreeTable	void (PLDHashTable *,
void *)*
	getKey		0x012014ce nsTHashtable<class
nsHostEntry>::s_GetKey(struct PLDHashTable *,struct PLDHashEntryHdr *)	  const
void * (PLDHashTable *, PLDHashEntryHdr *)*
	hashKey 	0x0120140b nsTHashtable<class
nsHostEntry>::s_HashKey(struct PLDHashTable *,void const *)	  unsigned int
(PLDHashTable *, const void *)*
	matchEntry	0x01201a2d nsTHashtable<class
nsHostEntry>::s_MatchEntry(struct PLDHashTable *,struct PLDHashEntryHdr const
*,void const *)     int (PLDHashTable *, const PLDHashEntryHdr *, const void
*)*
	moveEntry	0x0121b7a6 PL_DHashMoveEntryStub	void
(PLDHashTable *, const PLDHashEntryHdr *, PLDHashEntryHdr *)*
	clearEntry	0x0120152d nsTHashtable<class
nsHostEntry>::s_ClearEntry(struct PLDHashTable *,struct PLDHashEntryHdr *)     
  void (PLDHashTable *, PLDHashEntryHdr *)*
	finalize	0x0121b7a0 PL_DHashFinalizeStub void (PLDHashTable *)*
	initEntry	0x0120156e nsTHashtable<class
nsHostEntry>::s_InitEntry(struct PLDHashTable *,struct PLDHashEntryHdr *,void
const *)    void (PLDHashTable *, PLDHashEntryHdr *, const void *)*


... which is much more sensible than above, and there are no more crashes.

Comment 5

[[e-mail]]

oh wow, that's really interesting... thanks keeda!

bsmedberg has a pending patch to nsTHashtable, bug 201034. his patch touches
(amongst a bunch of other things) the AllowMemMove() stuff. This may
inadvertently fix the problem (or otherwise) - would it be possible for you to
apply the patch in that bug, and test it out?

that would give us at least one extra option to fix this, in a less hacky way
(presuming it works).

Comment 6

[Benjamin Smedberg]

OK, I don't know why this is a problem, but I think that bug 201034 will fix it
anyway, which I can checkin later today. If this is a smoketest blocker, the
one-liner above is fine as a temporary hack.

Comment 7

[Alec Flett]

Comment on attachment 121416 [details] [diff] [review]
Hack! 

well, sr=alecf if you need it as a temporary hack.

Comment 8

[Harshal Pradhan]

The patch from bug 201034 does indeed fix this too. (You need to add an enum to 
nsHostEntry to make it compile, of course.)

Comment 9

[Benjamin Smedberg]

Fixed checked in from bug 201034.