Closed Bug 525755 Opened 15 years ago Closed 15 years ago

crash [@ nsZipArchive::BuildFileList] using jar: with the file protocol without a '/' for the root of the filesystem

Categories

(Core :: Networking: JAR, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta5-fixed

People

(Reporter: msclrhd, Assigned: taras.mozilla)

References

(Depends on 1 open bug, )

Details

(Keywords: crash)

Crash Data

Attachments

(1 file, 1 obsolete file)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b2pre) Gecko/20091031 Ubuntu/9.10 (karmic) Namoroka/3.6b2pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b2pre) Gecko/20091031 Ubuntu/9.10 (karmic) Namoroka/3.6b2pre Given: <p><a href="jar:file:///foo.zip!/default.html">foo</a></td> <p><a href="jar:file://bar.zip!/default.html">bar</a></td> foo does not crash, but bar crashes Firefox (including any other open Firefox windows). NOTE: Firefox 3.5.3 (Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.3) Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3) does not show this behaviour -- it does not crash on the bar link. Reproducible: Always Steps to Reproduce: 1. Navigate to jar:file://bar.zip!/default.html Actual Results: Firefox crashes into oblivion! Expected Results: Nothing should happen (same as jar:file:///bar.zip!/default.html).
Same happens on latest nightly. Confirming. 03643aed-211c-4ca3-ac20-8d7342091101 There are only 11 of these crashes, now.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: crash using jar: with the file protocol without a '/' for the root of the filesystem → crash @nsZipArchive::BuildFileList() using jar: with the file protocol without a '/' for the root of the filesystem
OS: Linux → All
Hardware: x86 → All
Version: unspecified → Trunk
Component: File Handling → Networking: JAR
Keywords: crash
Product: Firefox → Core
QA Contact: file.handling → networking.jar
Summary: crash @nsZipArchive::BuildFileList() using jar: with the file protocol without a '/' for the root of the filesystem → crash [@ nsZipArchive::BuildFileList] using jar: with the file protocol without a '/' for the root of the filesystem
Flags: blocking1.9.2?
Attached patch first stab (obsolete) (deleted) — Splinter Review
Interesting bug. Seems that the url gets parsed into an nsIFile "/" which PR_Read then opens AND PR_Available reports a bogus length on and PR_MemMap fails(instead of PR_CreateFileMap as is normally the case). I'll add a testcase for this and run it on the tryserver to make sure we handle this correctly on all platforms.
Assignee: nobody → tglek
Interesting. Since you mention nsIFile resolving to "/", I decided to test jar:file:///!/foo.html which also crashes. Q: Since NS_ERROR_FAILURE is returned in your patch for this, does that result in nothing happening (as per the jar:file:///foo.zip!/default.html behaviour), or does it show a 'file not found' error (as per file:///foo.html)? In theory this is a separate bug, as 'file not found' should be displayed in this case, in the foo.zip case and in the jar:file:///valid.zip!/unknown.html cases. Should I raise a separate bug for this?
(In reply to comment #3) > Interesting. > > Since you mention nsIFile resolving to "/", I decided to test > jar:file:///!/foo.html which also crashes. Yup. > > Q: Since NS_ERROR_FAILURE is returned in your patch for this, does that result > in nothing happening (as per the jar:file:///foo.zip!/default.html behaviour), > or does it show a 'file not found' error (as per file:///foo.html)? > > In theory this is a separate bug, as 'file not found' should be displayed in > this case, in the foo.zip case and in the jar:file:///valid.zip!/unknown.html > cases. Should I raise a separate bug for this? You are right that should be a separate bug.
Not blocking the release for this, but if this patch gets reviewed and baked in time for the release (like, real soon), we could consider taking this crash fix.
Flags: blocking1.9.2? → blocking1.9.2-
Attached patch patch (deleted) — Splinter Review
Attachment #409825 - Attachment is obsolete: true
Attachment #410109 - Flags: review?(alfredkayser)
Attachment #410109 - Flags: review?(alfredkayser) → review+
Flags: wanted1.9.2?
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Attachment #410109 - Flags: approval1.9.2?
Depends on: 510844
Blocks: 531231
This is a crashfix, low risk for 192
Attachment #410109 - Flags: approval1.9.2? → approval1.9.2+
Comment on attachment 410109 [details] [diff] [review] patch a=me per discussion w/ beltzner et al.
Depends on: 574339
Crash Signature: [@ nsZipArchive::BuildFileList]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: