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)
Tracking
()
RESOLVED
FIXED
mozilla7
People
(Reporter: bent.mozilla, Assigned: taras.mozilla)
References
Details
(Whiteboard: [MemShrink:P3][inbound])
Attachments
(1 file)
796 bytes,
patch
|
mwu
:
review+
|
Details | Diff | Splinter Review |
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.
![]() |
Assignee | |
Comment 1•14 years ago
|
||
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
![]() |
||
Comment 3•14 years ago
|
||
(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]
Comment 4•14 years ago
|
||
(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).
![]() |
||
Comment 5•14 years ago
|
||
(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]
Comment 6•14 years ago
|
||
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.
![]() |
Assignee | |
Comment 7•14 years ago
|
||
Can someone confirm this fixes the leak?
Attachment #540887 -
Flags: review?
Comment 8•14 years ago
|
||
This fixes the leak I was hitting.
![]() |
Assignee | |
Updated•14 years ago
|
Attachment #540887 -
Flags: review? → review?(mwu)
Comment 9•14 years ago
|
||
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+
![]() |
Assignee | |
Comment 10•14 years ago
|
||
Whiteboard: [MemShrink:P3] → [inbound]
Updated•14 years ago
|
Whiteboard: [inbound] → [MemShrink:P3][inbound]
Comment 11•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
![]() |
||
Updated•14 years ago
|
Assignee: nobody → taras.mozilla
You need to log in
before you can comment on or make changes to this bug.
Description
•