Closed Bug 653936 Opened 14 years ago Closed 14 years ago

StartupCache uses nsZipItemPtr without ensuring that the JAR module is loaded, causes leaks

Categories

(Core :: XPCOM, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla7

People

(Reporter: bent.mozilla, Assigned: taras.mozilla)

References

Details

(Whiteboard: [MemShrink:P3][inbound])

Attachments

(1 file)

I'm seeing these leaks: 86 Monitor 32 32 110 1 ( 28.01 +/- 13.04) 0 0 ( 0.00 +/- 0.00) 87 Mutex 24 48 158 2 ( 54.25 +/- 22.28) 0 0 ( 0.00 +/- 0.00) 531 nsRecyclingAllocator 72 72 2 1 ( 1.33 +/- 0.58) 0 0 ( 0.00 +/- 0.00) 631 nsTArray_base 8 8 24033 1 ( 7143.94 +/- 3456.85) 0 0 ( 0.00 +/- 0.00) 642 nsThread 224 224 13 1 ( 6.52 +/- 3.38) 656 1 ( 64.98 +/- 21.83) 646 nsTimerImpl 104 104 53 1 ( 16.79 +/- 7.00) 279 1 ( 36.31 +/- 13.05) Basically it looks like the nsRecyclingAllocator is set to a global (gZlibAllocator) that is only freed in nsJarShutdown(), but nsJarShutdown() is only called if the JAR module has been loaded. Apparently using a raw nsZIPItemPtr in StartupCache does not cause the module to be loaded, so we leak.
This only happens in builds run from dist/bin because no jars get loaded(thus no nsJarShutdown). There are 2 solutions here: a) modify nsJARProtocolHandler::GetSingleton to initialize the custom allocator b) get rid of the custom allocator because we do not have any data on it making any difference
Blocks: mlk-fx7
(In reply to comment #1) > This only happens in builds run from dist/bin because no jars get > loaded(thus no nsJarShutdown). Is that *not* what normal users do?
Whiteboard: [MemShrink:P2]
(In reply to comment #3) > (In reply to comment #1) > > This only happens in builds run from dist/bin because no jars get > > loaded(thus no nsJarShutdown). > > Is that *not* what normal users do? That's what normal developers do. Normal users run packaged builds which usually involves at least one jar (the omnijar).
(In reply to comment #4) > > > This only happens in builds run from dist/bin > > That's what normal developers do. Normal users run packaged builds which > usually involves at least one jar (the omnijar). Ok, thanks; I've downgraded the MemShrink priority accordingly.
Whiteboard: [MemShrink:P2] → [MemShrink:P3]
This interferes with finding leaks with fuzzing. In particular, it means I'm not finding leaks that only leak nsTArray_base or only leak nsTimerImpl.
Attached patch workaroundSplinter Review
Can someone confirm this fixes the leak?
Attachment #540887 - Flags: review?
This fixes the leak I was hitting.
Attachment #540887 - Flags: review? → review?(mwu)
Comment on attachment 540887 [details] [diff] [review] workaround Well.. ok, sure. We should probably have a follow up bug on fixing this more elegantly.
Attachment #540887 - Flags: review?(mwu) → review+
Whiteboard: [MemShrink:P3] → [inbound]
Whiteboard: [inbound] → [MemShrink:P3][inbound]
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
Assignee: nobody → taras.mozilla
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: