ZIP corruption on startup loading jar files

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
18 years ago
16 years ago

People

(Reporter: darin.moz, Assigned: dveditz)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
On a multi-processor linux box, I frequently find the JAR decoder crapping out.
It seems like there are two JAR files being opened simultaneously, and this
could be leading to the corruption.  As a result, the browser window fails to
open properly (usually displaying nothing but the window manager's frame).

I've traced the error to mozilla/modules/libjar/nsZipArchive.cpp:468 (the
call to InflateItem fails).

Could this be regression of bug 51267?
(Assignee)

Comment 1

18 years ago
It could be similar to bug 51267, but the locking that fixed that bug is still 
in place. Since that fix there has been the addition of a "TestArchive" API, 
and the 'Jar cache' to make chrome perform better.

The Test API needs locking, but since it's not yet used except by XPInstall we 
can dismiss that. The nsZipReaderCache at first glance appears to do 
appropriate locking, but there's enough going on that it's certainly worth 
taking a closer look.

Do you have any more of a stack trace, which might implicate or clear 
nsZipReaderCache?

When you say "two JAR files being opened simultaneously" do you mean the same 
JAR being opened twice, or two completely different JARs?

Hyatt is definitely the wrong person but not sure who owns libjar these days. 
I'll grab it for now, unless someone on the CC list wants to take a crack 
at it. Will definitely need debugging help from someone with a multi-processor 
linux box :-)
Assignee: hyatt → dveditz
(Reporter)

Comment 2

18 years ago
I noticed it with two completely different JARs (which should be okay, right??).
The problem is hidden when I reduce the number of file transport threads to 1,
and (as I've said) the problem only appears to show up on a multiprocessor
machine.  So, it definitely sounds like some sort of locking problem.

I will try to generate a more complete stack trace when I get the chance.
The problem appears somewhat infrequently (maybe 1 out of every 10 loads).
(Assignee)

Comment 3

18 years ago
Darin: are you still seeing this problem?
(Reporter)

Comment 4

18 years ago
actually, i haven't seen this in a very long time.
(Assignee)

Comment 5

18 years ago
This hasn't been seen in a long while, here's hoping...
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
Moving all threading bugs to XPCOM. See bug 160356.
Component: Threading → XPCOM
You need to log in before you can comment on or make changes to this bug.