The default bug view has changed. See this FAQ.

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.