Closed
Bug 26295
Opened 25 years ago
Closed 24 years ago
"Channel list is not empty" assert on canceling page load.
Categories
(Core :: Networking, defect, P3)
Tracking
()
RESOLVED
FIXED
People
(Reporter: e75644, Assigned: rpotts)
References
()
Details
(Whiteboard: stack trace)
Attachments
(2 files)
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.
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)
Assignee: leger → gagan
Component: Browser-General → Networking
Whiteboard: stack trace
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)
Updated•25 years ago
|
Target Milestone: M15
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
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.
M16 has been out for a while now, these bugs target milestones need to be updated.
Comment 9•24 years ago
|
||
Please update target; M16 is long gone. I also reported this more recently as bug 46410
Assignee | ||
Comment 10•24 years ago
|
||
*** Bug 46410 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 11•24 years ago
|
||
*** Bug 41282 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
Clearing very old milestone (M16) in hope of reevaluation.
Target Milestone: M16 → ---
Assignee | ||
Comment 13•24 years ago
|
||
*** Bug 67473 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 14•24 years ago
|
||
Assignee | ||
Comment 15•24 years ago
|
||
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?
Assignee | ||
Comment 17•24 years ago
|
||
Fortunately, the LoadGroup is not multi-threaded... So no locks are necessary. -- rick
Assignee | ||
Comment 18•24 years ago
|
||
*** Bug 63145 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•24 years ago
|
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 19•24 years ago
|
||
I've just cheked in a patch (attached to bug #63529) which fixes this...
You need to log in
before you can comment on or make changes to this bug.
Description
•