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)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 76431

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.
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?
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
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?
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
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 :-)
-> 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

*** This bug has been marked as a duplicate of 76431 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.