e75644 Reporter
	Description • 25 years ago

As the topic says. Happened while http://www.sofor.fi was loading, I clicked on 
one of the bars at bottom to get forward, and Mozilla ran into said assert at:
NTDLL! 77f762e8()
nsDebug::Assertion(char * 0x0159b388, char * 0x0159b37c, char * 0x0159b350, int 
231) line 189 + 13 bytes
nsLoadGroup::Cancel(nsLoadGroup * const 0x02dcd250) line 231 + 32 bytes
nsDocLoaderImpl::Stop(nsDocLoaderImpl * const 0x02dcd1d0) line 201 + 26 bytes
nsDocLoaderImpl::Stop(nsDocLoaderImpl * const 0x025e0c00) line 197
nsWebShell::StopBeforeRequestingURL(nsWebShell * const 0x013fbe90) line 2281
nsWebShell::DoLoadURL(nsIURI * 0x03220d70, char * 0x0037d618, nsIInputStream * 
0x00000000, unsigned int 0, const unsigned int 0, unsigned short * 0x0320a120, 
int 1) line 1655
nsWebShell::LoadURI(nsWebShell * const 0x013fbe90, nsIURI * 0x03220d70, char * 
0x0037d618, nsIInputStream * 0x00000000, int 1, unsigned int 0, const unsigned 
int 0, nsISupports * 0x00000000, unsigned short * 0x0320a120) line 2019 + 40 
bytes
nsWebShell::LoadURL(nsWebShell * const 0x013fbe90, unsigned short * 0x03208770, 
char * 0x0037d618, nsIInputStream * 0x00000000, int 1, unsigned int 0, const 
unsigned int 0, nsISupports * 0x00000000, unsigned short * 0x0320a120) line 2238 
+ 52 bytes
nsWebShell::HandleLinkClickEvent(nsIContent * 0x031a2bcc, nsLinkVerb 
eLinkVerb_Replace, unsigned short * 0x03208770, unsigned short * 0x032091a0, 
nsIInputStream * 0x00000000) line 2901
OnLinkClickEvent::HandleEvent() line 2688
HandlePLEvent(OnLinkClickEvent * 0x03208ea0) line 2701
PL_HandleEvent(PLEvent * 0x03208ea0) line 526 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00fd4e10) line 487 + 9 bytes
_md_EventReceiverProc(void * 0x014504f4, unsigned int 49535, unsigned int 0, 
long 16600592) line 975 + 9 bytes

Not much else I can deduce from the problem yet. Strange it happened while 
trying to get to reprouce bug 26276 though, so the two might be linked. 'count' 
is actually 6. mForegroundCount is 6 too, so that would be next assert. I'm not 
immediately sure how this can happen, since I don't see an assert for NULL 
channel value having been encountered, which at first glance seems like only way 
to come through with count > 0. Might be optimizer caused code-movement and 
another thread modifying the pointer? If so, this can well be related to 26276 
and the general SMP problems.

	John Morrison
	Comment 1 • 25 years ago

 leger/Browser-General -> gagan/Networking

 e75644@uwasa.fi : just to confirm ...

1) This is reproducible for you, right? 
2) When you say "clicked on one of the bars at bottom" you're refering to
   one of the bars that says "Klikkaa!", right. And you just click this
   while the URL is loading and the assert fires?
3) You're running your own build from a recent CVS
4) You run WinNT SP6a on an SMP machine (as you noted on bug #26276)

	e75644 Reporter
	Comment 2 • 25 years ago

It happens every time I click on (apparently - haven't tried all, but most, 
including the bars and the image-links in middle) anything on the page while 
it's loading. The 'count' and 'mForegroundCount' are always 6 no matter 
what moment of the loading I do this. Happens with current (tree closed) CVS 
pull. WinNT SP6a on SMP machine with plenty of RAM and VC5.0 SP3.

If I let the page load without interrupting, quitting the browser will still 
fire assertion "Failure to shut down memory cache cleanly." From stack trace:

NTDLL! 77f762e8()
nsDebug::Assertion(char * 0x02a97498, char * 0x02a97470, char * 0x02a9743c, int 
56) line 189 + 13 bytes
nsDebug::WarnIfFalse(char * 0x02a97498, char * 0x02a97470, char * 0x02a9743c, 
int 56) line 245 + 21 bytes
nsMemCache::~nsMemCache() line 56 + 54 bytes
nsMemCache::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsMemCache::Release(nsMemCache * const 0x0262d8e0) line 69 + 131 bytes
(Shortened)

	Gagan
	Comment 3 • 25 years ago

loadgrps->rpotts

	leger
	Comment 4 • 25 years ago

Updating QA Contact.

	e75644 Reporter
	Comment 5 • 25 years ago

There seems to be some changes with regard to this problem in the lates builds, 
altough it could be because the site itself has changed. At first I was unable 
to move to next page while this page was loading, making me think it had been 
fixed in some way, but clicking on other links allowed me to reproduce the 
problem. In addition the same assert seems to be generated, but without 
debugger access, if shutting down the browser in midst of the loading. Letting 
the page load and then browsing along produced following asserion:

Assertion::~Assertion() line 138 + 15 bytes
Assertion::`scalar deleting destructor'(unsigned int 1) + 15 bytes
InMemoryDataSource::DeleteForwardArcsEntry(PLHashEntry * 0x025e8280, int 58, 
void * 0x00000000) line 670 + 28 bytes
PL_HashTableEnumerateEntries(PLHashTable * 0x025e88d0, int (PLHashEntry *, int, 
void *)* 0x01c33a20 InMemoryDataSource::DeleteForwardArcsEntry(PLHashEntry *, 
int, void *), void * 0x00000000) line 368 + 15 bytes
InMemoryDataSource::~InMemoryDataSource() line 645 + 19 bytes
InMemoryDataSource::`scalar deleting destructor'(unsigned int 1) + 15 bytes
InMemoryDataSource::Internal::Release(InMemoryDataSource::Internal * const 
0x025e889c) line 678 + 143 bytes
InMemoryDataSource::Release(InMemoryDataSource * const 0x025e8880) line 678 + 21 
bytes
nsBookmarksService::Release(nsBookmarksService * const 0x025e99f0) line 2568 + 
18 bytes
DeleteEntry(nsHashKey * 0x026053a0, void * 0x02605360, void * 0x00000000) line 
210 + 18 bytes
_hashEnumerateRemove(PLHashEntry * 0x026053e0, int 64, void * 0x0012fdc8) line 
227 + 26 bytes
PL_HashTableEnumerateEntries(PLHashTable * 0x00fc4c80, int (PLHashEntry *, int, 
void *)* 0x10013c20 _hashEnumerateRemove(PLHashEntry *, int, void *), void * 
0x0012fdc8) line 368 + 15 bytes
nsHashtable::Reset(int (nsHashKey *, void *, void *)* 0x1004da30 
DeleteEntry(nsHashKey *, void *, void *), void * 0x00000000) line 243 + 20 bytes
nsObjectHashtable::Reset() line 344
nsObjectHashtable::~nsObjectHashtable() line 309 + 8 bytes
nsObjectHashtable::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsServiceManagerImpl::~nsServiceManagerImpl() line 235 + 31 bytes
nsServiceManagerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsServiceManagerImpl::Release(nsServiceManagerImpl * const 0x00fc4c00) line 244 
+ 132 bytes
nsServiceManager::ShutdownGlobalServiceManager(nsIServiceManager * * 0x00000000) 
line 484 + 17 bytes
NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 585 + 7 bytes
main(int 1, char * * 0x00fc47c0) line 801 + 8 bytes
mainCRTStartup() line 338 + 17 bytes

	e75644 Reporter
	Comment 6 • 25 years ago

The second stack trace I submitted is probably bug 26608 and not related. I keep  
getting it much of the time on exit, altough that site (http://www.sofor.fi) 
seems to be pretty good place to get it.

	Warren Harris
	Comment 7 • 25 years ago

Moving what's not done for M15 to M16.

	Mike
	Comment 8 • 25 years ago

M16 has been out for a while now, these bugs target milestones need to be 
updated.

	Randell Jesup [:jesup] (needinfo me)
	Comment 9 • 24 years ago

Please update target; M16 is long gone.

I also reported this more recently as bug 46410

	rpotts (gone) Assignee
	Comment 10 • 24 years ago

*** Bug 46410 has been marked as a duplicate of this bug. ***

	rpotts (gone) Assignee
	Comment 11 • 24 years ago

*** Bug 41282 has been marked as a duplicate of this bug. ***

	Péter Bajusz
	Comment 12 • 24 years ago

Clearing very old milestone (M16) in hope of reevaluation.

	rpotts (gone) Assignee
	Comment 13 • 24 years ago

*** Bug 67473 has been marked as a duplicate of this bug. ***

	Judson Valeski
	Comment 16 • 24 years ago

patch looks fine as long as there are no threading issues in load groups. do we 
need locks in here?

	rpotts (gone) Assignee
	Comment 17 • 24 years ago

Fortunately, the LoadGroup is not multi-threaded...  So no locks are necessary.

-- rick

	rpotts (gone) Assignee
	Comment 18 • 24 years ago

*** Bug 63145 has been marked as a duplicate of this bug. ***

	rpotts (gone) Assignee
	Comment 19 • 24 years ago

I've just cheked in a patch (attached to bug #63529) which fixes this...