24642 - http://www.win98central.com/#437 gives me error

Status: VERIFIED DUPLICATE of bug 21556

(Core :: Networking, defect, P3)

Description

[Henrik Gemal]

- 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

Comment 1

[leger]

PDT+ works in 4.7

Comment 2

[Gagan]

Andreas could you verify this? 

Comment 3

[Andreas Otte]

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

Comment 4

[Andreas Otte]

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. 

Comment 5

[Andreas Otte]

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. 

Comment 6

[Gagan]

seems like a problem in the layout. the url isn't valid anymore... could the
reporter try and submit another? to layout...

Comment 7

[Henrik Gemal]

http://www.win98central.com/#643

Comment 8

[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.

Comment 9

[Warren Harris]

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.

Comment 10

[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

Comment 11

[Warren Harris]

That one is bug 23263. 

Comment 12

[Andreas Otte]

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

[rickg]

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.

Comment 14

[Warren Harris]

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.

Comment 15

[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. 

Comment 16

[Andreas Otte]

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

[Gagan]

temp fix checked in... this will take away the crash. 

Comment 18

[rpotts (gone)]

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

Comment 19

[Warren Harris]

Let's back it out.

Comment 20

[leger]

Can you give new ETA for fix please?

Comment 21

[Gagan]

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

Comment 22

[Gagan]

oops wrong dup

Comment 23

[Gagan]

now the correct one bug 21556

*** This bug has been marked as a duplicate of 21556 ***

Comment 24

[Tom Everingham]

verified dupe of 21556

Comment 25

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/a4f5d9795138
[fenix] For https://github.com/mozilla-mobile/fenix/issues/24642 - Remove Event.wrapper for TopSites metrics