Closed Bug 421828 Opened 14 years ago Closed 14 years ago
about:cache hexdump does not truncate buffer, overwrites counter
If you attempt to view or save an about:cache entry of, say, 1.5MiB, it will result in a 1.8GiB file with the start of the file repeating every 4096 bytes. Adding buffer.Truncate() after: 396 outputStream->Write(buffer.get(), buffer.Length(), &n); And, as was noted by biesi, moving the dataSize -= n; to before it, pre-clobbering of n, avoids halting the dump prematurely.
This apparently has an easy fix and can kill Firefox under certain conditions as well as cause a mess. Going to nominate to block1.9.
Version: unspecified → Trunk
This isn't something we'd block the release for as I believe this is an unusual use case. However, we should fix this. Marking wanted1.9.0.x+.
... adding an extra line of code and moving another can't make it in prior to 1.9? :) Anyway, I don't think the use case is that unusual. I and others often use about:cache as a way to save flash vids when no other obvious interface presents itself. There are a few how-tos on this online. But, just glad someone is looking at it again. Thanks Quan.
Not blocking doesn't mean it can't make it in. Just means it won't block the release. :)
This patch does the things mentioned in the bug description. IMHO putting that hexdump in there was not the best thing to do in the first place. It takes huge amounts of memory (about 30 x <cache entry size> on my machine) and quite some time to render with large files. How about hexdumping just the first ~50000 bytes?
Attachment #315150 - Flags: review?(cbiesinger)
14 years ago
Attachment #315150 - Flags: review?(cbiesinger) → review+
Comment on attachment 315150 [details] [diff] [review] do things mentioned in bug description sr=bzbarsky
Attachment #315150 - Flags: superreview?(bzbarsky) → superreview+
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
You need to log in before you can comment on or make changes to this bug.