19 years ago
19 years ago


(Reporter: Henrik Gemal, Assigned: Gagan)


Windows 98

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+], URL)



19 years ago
- Start Mozilla
- Enter in the URL and press enter.

I'm getting:
Error loading URL

Mozilla loads the page and goes to anchor 437

Using build 2000012008


19 years ago
Keywords: beta1
Target Milestone: M14

Comment 1

19 years ago
PDT+ works in 4.7
Whiteboard: [PDT+]

Comment 2

19 years ago
Andreas could you verify this? 
Assignee: gagan → andreas.otte

Comment 3

19 years ago
*** Bug 25185 has been marked as a duplicate of this bug. ***

Comment 4

19 years ago
I can verify this is happening, although tried it with ... #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. 

Comment 5

19 years ago
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
Assignee: andreas.otte → gagan

Comment 6

19 years ago
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

Comment 8

19 years ago
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

Comment 9

19 years ago
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

Comment 10

19 years ago
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 

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

Comment 11

19 years ago
That one is bug 23263. 

Comment 12

19 years ago
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.

Comment 13

19 years ago
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()

I'm handing this bug back to you until we're sure this isn't a networking 
Assignee: rickg → warren

Comment 14

19 years ago
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

Comment 15

19 years ago
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 
Whiteboard: [PDT+] → [PDT+] ETA 02/22/00

Comment 16

19 years ago
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.

Comment 17

19 years ago
temp fix checked in... this will take away the crash. 

Comment 18

19 years ago
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 

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!!!

Comment 19

19 years ago
Let's back it out.

Comment 20

19 years ago
Can you give new ETA for fix please?

Comment 21

19 years ago
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 ***
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
Whiteboard: [PDT+] ETA 02/22/00 → [PDT+]

Comment 22

19 years ago
oops wrong dup
Resolution: DUPLICATE → ---

Comment 23

19 years ago
now the correct one bug 21556

*** This bug has been marked as a duplicate of 21556 ***
Last Resolved: 19 years ago19 years ago
Resolution: --- → DUPLICATE

Comment 24

19 years ago
verified dupe of 21556
You need to log in before you can comment on or make changes to this bug.