Closed Bug 20419 Opened 25 years ago Closed 25 years ago

[dogfood] Clicking on links or typing a new URL doesn't load page

Categories

(Core :: Networking, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: chriss, Assigned: warrensomebody)

Details

(Whiteboard: [PDT-])

Build 1999113012
OS: Win98

Steps to reproduce:
1. Launch Seamonkey
2. Click on a link or bookmark - notice that page loads properly
3. Wait a minute or 2
4. Attempt to click on a link or type a URL and hit return
5. Notice that the status bar says the page has loaded (often quickly in less
than 1 sec) but no page appears.

I believe this bug is related to:
http://bugzilla.mozilla.org/show_bug.cgi?id=20416

Here's why: as soon as the ability to click on links breaks, I also cannot
make TCP connections in 4.7. Perhaps both these bugs have to do with a memory
leak?
Assignee: leger → gagan
Component: Browser-General → Networking-Core
QA Contact: leger → tever
Link problem looks like a dup of:
http://bugzilla.mozilla.org/show_bug.cgi?id=19510

URL problem looks like:
http://bugzilla.mozilla.org/show_bug.cgi?id=15150
a dup of http://bugzilla.mozilla.org/show_bug.cgi?id=20172

chriss, these are 2 seperate bugs.  Both I believe known.  I will continue ith
investigation, but next time...two bugs please :-)
I don't think this bug is related at all to:
http://bugzilla.mozilla.org/show_bug.cgi?id=15150

Also I don't think this should be 2 separate bugs, since both links and typing
URLs work until some point in time and then both fail simultaneously.

What I am seeing is a symptom of some underlying bug, perhaps a memory leak.
Adding warren@netscape.com and beard@netscape.com to cc: list per conversation
with warren.
Assignee: gagan → warren
Whiteboard: [PDT+]
Putting on PDT+ radar.
Target Milestone: M12
Jan, can we reproduce this or mark works for me.
As of the 199120808 build, this problem has gone away for me. Warren - did you
check in a fix or do something special to my machine?
No, we didn't check anything in for this (that I know of). [twlight zone theme]
We were suspecting the SSL i/o layering or perhaps the cartman process though.
I have not change anything with regard to ssl io layering in a while.  I can
reproduce this intermittenly when running/debugging in xpcshell.  This does not
touch ssl/https.  I am not sure exactly what the steps to reproduce are.
What is xpcshell? Are you saying other programs get the same winsock breakage?

Rick and I had determined that we were getting an error back from nspr from
connect (as I recall). Rick can confirm.
xpcshell is some test application that allows you to load pieces of JS code
and call them as functions from a command line (really cool).  I have been
using it to test nsIFile.  On a few occurances, I caused tcp to lock up.  I
thought that this was some problem regarding a new dsl modem, but the symtoms
in this bug report are similar to what I experienced.  The javascript that I
had loaded should not go through connect() and in fact is mostly string
parsing.  I have tried since to reproduce it without any luck.
Moving what's not done for M12 to M13.
Whiteboard: [PDT+]
Removing PDT+ to be reconsidered, this now works on Saito's machine as well.
Whiteboard: [PDT-]
Putting on the PDT- radar.  Only on chriss machine.
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
Chris: You said this problem went away for you, right? If so, can we mark this
WORKSFORME now? I'm not sure what else to do to try and track it down.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
We haven't seen this problem for weeks.
worksforme too - marking verified - 2000012520
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.