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

RESOLVED FIXED in mozilla7

Status

()

Core
XPCOM
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Ben Turner (not reading bugmail, use the needinfo flag!), Assigned: (dormant account))

Tracking

Trunk
mozilla7
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

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

6 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
Duplicate of this bug: 664630
Blocks: 659860
(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

6 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).
(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

6 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

6 years ago
Created attachment 540887 [details] [diff] [review]
workaround

Can someone confirm this fixes the leak?
Attachment #540887 - Flags: review?

Comment 8

6 years ago
This fixes the leak I was hitting.
(Assignee)

Updated

6 years ago
Attachment #540887 - Flags: review? → review?(mwu)

Comment 9

6 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

6 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/11e4980826aa
Whiteboard: [MemShrink:P3] → [inbound]

Updated

6 years ago
Whiteboard: [inbound] → [MemShrink:P3][inbound]
http://hg.mozilla.org/mozilla-central/rev/11e4980826aa
Status: NEW → RESOLVED
Last Resolved: 6 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.