Closed
Bug 24642
Opened 25 years ago
Closed 25 years ago
http://www.win98central.com/#437 gives me error
Categories
(Core :: Networking, defect, P3)
Tracking
()
M14
People
(Reporter: bugzilla, Assigned: gagan)
References
()
Details
(Whiteboard: [PDT+])
- 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
Andreas could you verify this?
Assignee: gagan → andreas.otte
Comment 4•25 years ago
|
||
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•25 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
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
Reporter | ||
Comment 7•25 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•25 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•25 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
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•25 years ago
|
||
That one is bug 23263.
Comment 12•25 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•25 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()
00656220()
I'm handing this bug back to you until we're sure this isn't a networking
problem.
Assignee: rickg → warren
Comment 14•25 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
Assignee | ||
Comment 15•25 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
changed NS_RELEASE to NS_IF_RELEASE.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] ETA 02/22/00
Comment 16•25 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.
Assignee | ||
Comment 17•25 years ago
|
||
temp fix checked in... this will take away the crash.
Comment 18•25 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
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•25 years ago
|
||
Let's back it out.
Comment 20•25 years ago
|
||
Can you give new ETA for fix please?
Assignee | ||
Comment 21•25 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 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Whiteboard: [PDT+] ETA 02/22/00 → [PDT+]
Assignee | ||
Comment 22•25 years ago
|
||
oops wrong dup
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee | ||
Comment 23•25 years ago
|
||
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•