Last Comment Bug 653936 - StartupCache uses nsZipItemPtr without ensuring that the JAR module is loaded, causes leaks
: StartupCache uses nsZipItemPtr without ensuring that the JAR module is loaded...
Status: RESOLVED FIXED
[MemShrink:P3][inbound]
:
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: x86 All
: -- normal with 1 vote (vote)
: mozilla7
Assigned To: (dormant account)
:
Mentors:
: 664630 (view as bug list)
Depends on:
Blocks: mlk-fx7
  Show dependency treegraph
 
Reported: 2011-04-30 11:36 PDT by Ben Turner (not reading bugmail, use the needinfo flag!)
Modified: 2012-01-14 00:27 PST (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
workaround (796 bytes, patch)
2011-06-21 14:15 PDT, (dormant account)
mwu.code: review+
Details | Diff | Splinter Review

Description Ben Turner (not reading bugmail, use the needinfo flag!) 2011-04-30 11:36:58 PDT
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.
Comment 1 (dormant account) 2011-05-02 10:38:54 PDT
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 2 Andrew McCreight [:mccr8] 2011-06-15 18:04:48 PDT
*** Bug 664630 has been marked as a duplicate of this bug. ***
Comment 3 Nicholas Nethercote [:njn] 2011-06-15 19:19:48 PDT
(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?
Comment 4 Michael Wu [:mwu] 2011-06-15 19:24:21 PDT
(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 Nicholas Nethercote [:njn] 2011-06-15 19:30:01 PDT
(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.
Comment 6 Jesse Ruderman 2011-06-21 13:45:51 PDT
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.
Comment 7 (dormant account) 2011-06-21 14:15:42 PDT
Created attachment 540887 [details] [diff] [review]
workaround

Can someone confirm this fixes the leak?
Comment 8 Jesse Ruderman 2011-06-24 09:26:39 PDT
This fixes the leak I was hitting.
Comment 9 Michael Wu [:mwu] 2011-06-29 17:28:10 PDT
Comment on attachment 540887 [details] [diff] [review]
workaround

Well.. ok, sure.

We should probably have a follow up bug on fixing this more elegantly.
Comment 11 Marco Bonardo [::mak] 2011-07-02 02:30:34 PDT
http://hg.mozilla.org/mozilla-central/rev/11e4980826aa

Note You need to log in before you can comment on or make changes to this bug.