- Start Mozilla - Enter http://www.win98central.com/#437 in the URL and press enter. I'm getting: Error loading URL http://www.win98central.com/#437 Expected: Mozilla loads the page and goes to anchor 437 Using build 2000012008
PDT+ works in 4.7
Andreas could you verify this?
Assignee: gagan → andreas.otte
*** Bug 25185 has been marked as a duplicate of this bug. ***
I can verify this is happening, although tried it with http://www.win98central.com/#643 ... #437 is no longer on the page. It seems to me mozilla trys to go to early to the anchor. It does not load the whole document and then trys to go to the anchor which is not there yet ... and fails. This may only happen with large documents and/or slow connections, I could not reproduce this with a small page against a local server.
Gagan, I have to give this one back to you. I'm at a complete loss here. It's seems to be a problem with timing/premature notifications that the page is loaded.
Assignee: andreas.otte → gagan
seems like a problem in the layout. the url isn't valid anymore... could the reporter try and submit another? to layout...
Assignee: gagan → rickg
Gagan -- I'm sending this back to you for further analysis. Please be more diligent before forwarding bugs to layout; our plate(s) are full too. When I load this page withtout the link spec, it's renders ok. Nav4x does it about as well, though a bit faster. Because this page renders slowly, I'm adding it to the top 100. Ultimately this page crashes in necko.
Assignee: rickg → gagan
Rick: Can you give a backtrace for the crash? I just tried it and the page rendered ok (no crash) (optimized build), but didn't go to the anchor specified in the URL. Seems like a layout bug to me.
Assignee: gagan → rickg
I see two different crashes, depending on whether I'm at home or work. I'll post the crash from home later tonight. At work, I see this when I close the window: nsDebug::Assertion(const char * 0x025d7498, const char * 0x025d7470, const char * 0x025d743c, int 56) line 189 + 13 bytes nsDebug::WarnIfFalse(const char * 0x025d7498, const char * 0x025d7470, const char * 0x025d743c, 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 0x02194de0) line 69 + 131 bytes nsCOMPtr<nsINetDataCache>::~nsCOMPtr<nsINetDataCache>() line 435 nsCacheManager::~nsCacheManager() line 67 + 33 bytes nsCacheManager::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsCacheManager::Release(nsCacheManager * const 0x02191e40) line 49 + 131 bytes DeleteEntry(nsHashKey * 0x02197ca0, void * 0x02197ce0, void * 0x00000000) line 210 + 18 bytes _hashEnumerateRemove(PLHashEntry * 0x02197c60, int 38, void * 0x0012fe00) line 227 + 26 bytes PL_HashTableEnumerateEntries(PLHashTable * 0x00ff4ba0, int (PLHashEntry *, int, void *)* 0x00243990 _hashEnumerateRemove(PLHashEntry *, int, void *), void * 0x0012fe00) line 368 + 15 bytes nsHashtable::Reset(int (nsHashKey *, void *, void *)* 0x0027cf50 DeleteEntry(nsHashKey *, void *, void *), void * 0x00000000) line 243 + 20 bytes nsObjectHashtable::Reset() line 344 nsObjectHashtable::~nsObjectHashtable() line 310 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 0x00ff4c40) line 244 + 132 bytes nsServiceManager::ShutdownGlobalServiceManager(nsIServiceManager * * 0x00000000) line 484 + 17 bytes NS_ShutdownXPCOM(nsIServiceManager * 0x00000000) line 546 + 7 bytes main(int 2, char * * 0x00ff1ac0) line 160 + 8 bytes mainCRTStartup() line 338 + 17 bytes
That one is bug 23263.
I also don't think this is a layout bug. I think we are getting a premature notification that the page has been loaded and we now can move to the anchor. But the page is not loaded and the anchor is not there, so we fail going there.
Warren: Here's the 2nd stack trace from my home machine. Note that get this crash about 40% of the time: nsHTTPChannel::~nsHTTPChannel() line 124 + 12 bytes nsHTTPChannel::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsHTTPChannel::Release(nsHTTPChannel * const 0x0228d0f0) line 134 + 137 bytes nsStreamListenerEvent::~nsStreamListenerEvent() line 77 + 27 bytes nsOnStopRequestEvent::~nsOnStopRequestEvent() line 258 + 8 bytes nsOnStopRequestEvent::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsStreamListenerEvent::DestroyPLEvent(PLEvent * 0x026a2bd0) line 104 + 30 bytes PL_DestroyEvent(PLEvent * 0x026a2bd0) line 549 + 10 bytes PL_HandleEvent(PLEvent * 0x026a2bd0) line 536 + 9 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00656220) line 487 + 9 bytes _md_EventReceiverProc(HWND__ * 0x074d03da, unsigned int 49355, unsigned int 0, long 6644256) line 975 + 9 bytes USER32! 77e71820() 00656220() I'm handing this bug back to you until we're sure this isn't a networking problem.
Assignee: rickg → warren
This is one for Gagan. Looks like a premature free of either the nsHTTPChannel (while destroying the event), or perhaps it's that the mRequest object inside the channel has already been freed (there's an NS_RELEASE at that line in the code instead of an NS_IF_RELEASE for some reason). Gagan, can you investigate? Note: I don't see a crash on my machine.
Assignee: warren → gagan
I dont see the crash either anymore (yes I did see it once) Either some recent changes have fixed this or it is not being duplicated correctly. I have however changed NS_RELEASE to NS_IF_RELEASE.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] ETA 02/22/00
I have also never seen the crash (on linux), but the main problem remains. The url does not load when called with a ref from the beginning. I see an error loading the url within three seconds, but then the load continues for some more seconds and then dies again with a partial layout. Loading the url without the ref part takes many many more seconds and succeeds.
temp fix checked in... this will take away the crash.
Arrrrrg!! Changing the NS_RELEASE(...) to an NS_IF_RELEASE(...) does *not* seem like a good fix. IT will only make it *harder* to find the underlying instability in the system. As far as I can see there are two possibilities: 1. There is a fundamental ownership problem in HTTP. Since the rest of the code does not check before dereferencing the pointer, we still have a potential crash. Unfortunately, this one wil be less frequent and thus harder to track down. 2. This is *really* a dup of bug #21556 and is a symptom of a lack of thread-safety within the system. In either case, changing the NS_RELEASE() to NS_IF_RELEASE() will only make it *harder* to find the REAL bug!!!
Let's back it out.
Can you give new ETA for fix please?
per rpotts I am marking this a dup of 21556. and as for removing the NS_IF_RELEASE i have made that debug only to help us catch this bug and still not have a crasher. waiting for approval to check that in.. *** This bug has been marked as a duplicate of 21566 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
Whiteboard: [PDT+] ETA 02/22/00 → [PDT+]
oops wrong dup
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → DUPLICATE
verified dupe of 21556
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.