Closed
Bug 124623
Opened 23 years ago
Closed 23 years ago
Mozilla reports "xxxxx could not be found" when page clearly exists
Categories
(Core :: Networking: Cache, defect)
Tracking
()
People
(Reporter: paul, Assigned: gordon)
Details
(Keywords: qawanted)
This is a really annoying problem, because I cannot track down what causes Mozilla to break. Sorry guys and gals, I have done my best. I describe the problem as follows: While browsing around a site, seemingly randomly, when attempting to following a link, Mozilla will claim that the page does not exist. However, this is rubbish, because often I will have just visited that link. The behaviour seems to occur when I have already followed a particular link. Manually typing the link does not work either. It requires me to restart Mozilla (child windows suffer the same problem) to correct the behaviour. However, I cannot reproduce this error at will, which is the annoying bit.
Comment 1•23 years ago
|
||
Reporter: Do you use 2 Mozilla instances ? (not supported !)
Ah, you mean instead of sticking rigidly to the new window (Ctrl-n) approach? Yeh, I suppose that some of the time I will have at least two instances of Mozilla open. Is this causing the problem then? If so, what is breaking?
Comment 3•23 years ago
|
||
Reporter: Why is this "critical" ("crashes, loss of data, severe memory leak")?
Mozilla becomes completely unusable after the first failure. OK, while this is not critical, there is no "really annoying" option. I have bumped it down to normal severity.
Severity: critical → normal
![]() |
||
Comment 5•23 years ago
|
||
Running more than one mozilla instance at once will corrupt the cache file as both instances try to write to it. As a result you _could_ see this behavior (if the cache data for a URL gets corrupted).
Hmmm, race condition. Is there no simple locking/semaphore scheme that can be employed to ensure atomic access to the cache?
Comment 7•23 years ago
|
||
see bug 76431 (Profiles needs to be protected from running multiple instances of mozilla) marking invalid -> Please reopen if you see this with one Mozilla instance.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Comment 8•23 years ago
|
||
REOPENING The user behavior (if correctly described) in invalid, but the bug report itself is valid. I'll mark it a duplicate pending user confirmation. (High duplicate counts give bugs more fix visibility). reporter: Can you answer Matti's question about the problem not happening if only one instance is running?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
I think I have answered his question. But, here's the answer I think you want: no, I cannot recall having seen this behaviour with one instance open. Frequently working from many machines with multiple instances, I cannot assure you that this hasn't happened with one instance; it may have done, but my instant reaction will have been to fire another instance. On that last point, I find this strange. If there is a race condition on certain profile files, why does creating another instance fix the problem? The broken instance does not start working when the new one appears incidentally. It seems there must be some error correction code somewhere that is run on startup; I guessing here however :-)
Comment 10•23 years ago
|
||
-> cache, default qa and owner +qawanted (DupeMe) (scratches head wondering why the REOPEN command moved status to UNCONFIRMED...) Paul: Thanks for the update. I was fairly certain you meant "yes", but when possible, we try to clarify problem descriptions from reporters. If you have a specific set of steps as an example (or a statement that it is annoyingly hard to reproduce), that is the most valuable information we get from bug reporters. To answer your question: If the problem is what we think it is, the reason closing all instances and running one instance solves the problem is because it re-initializes the cache on disk. When two instances run in the same profile, there is a collision. My recollection is that there is an actual cache bug, so moving this to cache and changing the defaults.
Assignee: new-network-bugs → gordon
Component: Networking → Networking: Cache
Keywords: qawanted
QA Contact: benc → tever
Assignee | ||
Comment 11•23 years ago
|
||
*** This bug has been marked as a duplicate of 76431 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•