1039914 - Heap-unclassified keeps increasing in array buffer transfer mochitest

Status: NEW

(Core :: Networking, defect, P3)

Description

[Shian-Yow Wu [:swu]]

+++ This bug was initially created as a clone of Bug #1037358 +++

When doing the interations of array buffer transfer in mochitest of bug 1037358, the "heap-unclassified" in about:memory keeps increasing, it indicates a potential memory leakage.

Comment 1

[Shian-Yow Wu [:swu]]

Attachment: DMD report

Attached is the DMD report.  It shows that the unreported heap blocks are increased steadily, mostly coming from Necko cache.

Initial:
  Unreported:      ~20,904,573 bytes ( 27.66%) in  ~3,765 blocks ( 27.93%)
10000 iterations:
  Unreported:      ~39,070,543 bytes ( 38.36%) in  ~7,672 blocks ( 38.13%)
20000 iterations:
  Unreported:      ~55,664,927 bytes ( 52.46%) in ~11,296 blocks ( 53.72%)
30000 iterations:
  Unreported:      ~82,342,680 bytes ( 61.95%) in ~16,587 blocks ( 63.09%)

Comment 2

[Shian-Yow Wu [:swu]]

Another major part of unreported heap is coming from DOM worker.

Comment 3

[Shian-Yow Wu [:swu]]

Attachment: Test case to reproduce

Comment 4

[Shian-Yow Wu [:swu]]

(In reply to Shian-Yow Wu [:shianyow] from comment #2)
> Another major part of unreported heap is coming from DOM worker.

Filed bug 1040592 for leakage related to DOM worker.

Comment 5

[Shian-Yow Wu [:swu]]

Per bug 1040592 comment 4, a large of proportion of memory is being used in the deadlock detector, including cache and workers.

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Unreported: ~332 blocks in stack trace record 2 of 2,542
 ~1,358,876 bytes (~1,358,876 requested / ~0 slop)
 1.02% of the heap (7.33% cumulative);  1.65% of unreported (11.84% cumulative)
 Allocated at
   replace_malloc (/home/sywu/work/mozilla-central/memory/replace/dmd/DMD.cpp:1245) 0x75c165d0
   _PR_Getfd (/home/sywu/work/mozilla-central/nsprpub/pr/src/io/prfdcach.c:113) 0x743c5660
   pt_SetMethods (/home/sywu/work/mozilla-central/nsprpub/pr/src/pthreads/ptio.c:3305) 0x743e4976
   PR_OpenFile (/home/sywu/work/mozilla-central/nsprpub/pr/src/pthreads/ptio.c:3582) 0x743e51a6
   nsLocalFile::OpenNSPRFileDesc(int, int, PRFileDesc**) (/home/sywu/work/mozilla-central/xpcom/io/nsLocalFileUnix.cpp:397) 0x6eae7b33
   nsDiskCacheStreamIO::OpenCacheFile(int, PRFileDesc**) (/home/sywu/work/mozilla-central/netwerk/cache/nsDiskCacheStreams.cpp:532) 0x6ec0a2f4
   nsDiskCacheStreamIO::GetInputStream(unsigned int, nsIInputStream**) (/home/sywu/work/mozilla-central/netwerk/cache/nsDiskCacheStreams.cpp:260) 0x6ec0ad5d
   nsCOMPtr<nsIInputStream>::get() const (/home/sywu/work/mozilla-central/obj-x86_64-debug/netwerk/cache/../../dist/include/nsCOMPtr.h:815) 0x6ebed4ef
   nsCacheEntryDescriptor::nsInputStreamWrapper::Read_Locked(char*, unsigned int, unsigned int*) (/home/sywu/work/mozilla-central/netwerk/cache/nsCacheEntryDescriptor.cpp:818) 0x6ebed5b6
   nsCacheEntryDescriptor::nsInputStreamWrapper::Read(char*, unsigned int, unsigned int*) (/home/sywu/work/mozilla-central/netwerk/cache/nsCacheEntryDescriptor.cpp:811) 0x6ebed80e
   nsInputStreamTransport::Read(char*, unsigned int, unsigned int*) (/home/sywu/work/mozilla-central/netwerk/base/src/nsStreamTransportService.cpp:199) 0x6eb9a48d
   nsStreamCopierOB::FillOutputBuffer(nsIOutputStream*, void*, char*, unsigned int, unsigned int, unsigned int*) (/home/sywu/work/mozilla-central/xpcom/io/nsStreamUtils.cpp:560) 0x6eaff00d
   nsPipeOutputStream::WriteSegments(tag_nsresult (*)(nsIOutputStream*, void*, char*, unsigned int, unsigned int, unsigned int*), void*, unsigned int, unsigned int*) (/home/sywu/work/mozilla-central/xpcom/io/nsPipe3.cpp:1169) 0x6eaf7637
   nsStreamCopierOB::DoCopy(tag_nsresult*, tag_nsresult*) (/home/sywu/work/mozilla-central/xpcom/io/nsStreamUtils.cpp:577) 0x6eaff636
   nsAStreamCopier::Process() (/home/sywu/work/mozilla-central/xpcom/io/nsStreamUtils.cpp:292) 0x6eaff848
   nsAStreamCopier::Run() (/home/sywu/work/mozilla-central/xpcom/io/nsStreamUtils.cpp:417) 0x6eaffba1
   nsThreadPool::Run() (/home/sywu/work/mozilla-central/xpcom/threads/nsThreadPool.cpp:221) 0x6eb10fdb
   nsThread::ProcessNextEvent(bool, bool*) (/home/sywu/work/mozilla-central/xpcom/threads/nsThread.cpp:766) 0x6eb10ae6
   NS_ProcessNextEvent(nsIThread*, bool) (/home/sywu/work/mozilla-central/xpcom/glue/nsThreadUtils.cpp:256) 0x6eaa2d34
   mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) (/home/sywu/work/mozilla-central/ipc/glue/MessagePump.cpp:327) 0x6eda82c2
   MessageLoop::RunInternal() (/home/sywu/work/mozilla-central/ipc/chromium/src/base/message_loop.cc:230) 0x6ed862ac
   ~AutoRunState (/home/sywu/work/mozilla-central/ipc/chromium/src/base/message_loop.cc:504) 0x6ed86320
   nsThread::ThreadFunc(void*) (/home/sywu/work/mozilla-central/xpcom/threads/nsThread.cpp:355) 0x6eb106a5
   _pt_root (/home/sywu/work/mozilla-central/nsprpub/pr/src/pthreads/ptthread.c:215) 0x743e6de7

Comment 7

[Nathan Froyd [:froydnj]]

I think the PR FD caching code is wonky, but before fingering NSPR here, are we really supposed to have several thousand files opened by the new networking cache?

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

The NSPR thing is still an issue, so if you don't want to use this bug for that please file another.

Comment 9

[Michal Novotny [:michal]]

(In reply to Nathan Froyd (:froydnj) from comment #7)
> I think the PR FD caching code is wonky, but before fingering NSPR here, are
> we really supposed to have several thousand files opened by the new
> networking cache?

The number of opened files in the new cache is limited to 64 (http://hg.mozilla.org/mozilla-central/annotate/d0f6259e8446/netwerk/cache2/CacheFileIOManager.cpp#l49). From what log do you see that the new cache keeps several thousand files opened?

Comment 10

[Nathan Froyd [:froydnj]]

(In reply to Michal Novotny (:michal) from comment #9)
> The number of opened files in the new cache is limited to 64
> (http://hg.mozilla.org/mozilla-central/annotate/d0f6259e8446/netwerk/cache2/
> CacheFileIOManager.cpp#l49). From what log do you see that the new cache
> keeps several thousand files opened?

Thanks for the pointer to how the networking cache manages files here.

Comment 6 shows that we've allocated 1MB+ for NSPR's file descriptor objects, and that those allocations have occurred via the networking cache opening files.  I misread the log there, though; it looks as though only several hundred files have been opened.  Since those allocations are showing up in the DMD log, we've never freed all of those descriptors.  (We may have closed the files, though; NSPR caches the file descriptors for reasons that seem unclear.)

The log seems a little wonky, though, as 1.3MB / 332 blocks ~= 4K/block.  That's somewhat high for NSPR structures:

http://mxr.mozilla.org/nspr/source/pr/include/prio.h#52 (PRFileDesc)
http://mxr.mozilla.org/nspr/source/pr/include/private/primpl.h#1725 (PRFilePrivate)
http://mxr.mozilla.org/nspr/source/pr/src/io/prpolevt.c#44 (completely different PRFilePrivate definition)

neither of which looks to be nearly that large.  Tens of bytes, perhaps, instead of thousands.  Perhaps that's just due to DMD sampling?

Anyway, I notice that the log also shows the allocations coming from the original networking cache, rather than the new networking cache, which seems odd.  Shian-Yow, were these measurements taken with a recent build?  Do you have the new networking cache disabled?

Comment 11

[Nathan Froyd [:froydnj]]

Turns out we've known about the busted NSPR caching for four years: bug 573192.

Comment 12

[Shian-Yow Wu [:swu]]

(In reply to Nathan Froyd (:froydnj) from comment #10)
> Anyway, I notice that the log also shows the allocations coming from the
> original networking cache, rather than the new networking cache, which seems
> odd.  Shian-Yow, were these measurements taken with a recent build?  Do you
> have the new networking cache disabled?

It was measured with m-c build within 2 weeks, and with the follwoing two options, no specific options related to networking cache.
  --enable-debug
  --enable-dmd

Comment 13

[Shian-Yow Wu [:swu]]

Attachment: DMD report (release build)

This is the DMD report of release build from today's m-c.

No deadlock detector leakage in release build, however still seen NSPR leakage.

Comment 14

[Michal Novotny [:michal]]

For some reason your FF runs with the old cache. Did you use a new profile?

Comment 15

[Shian-Yow Wu [:swu]]

Attachment: DMD report (release build with new cache)

Attached is the DMD report with new cache enabled.

The new cache is disabled by default when testing with mochitest.
I have to pass the preference in mochitest to run with new cache:
  $./mach mochitest-plain content/base/test/test_bug1037358.html --dmd --setpref browser.cache.use_new_backend_temp=true

Comment 16

[Shian-Yow Wu [:swu]]

The #1 unreported record in attach file of comment 15.

Unreported: ~1,174 blocks in stack trace record 1 of 1,955
 ~4,805,182 bytes (~4,805,182 requested / ~0 slop)
 8.46% of the heap (8.46% cumulative);  18.07% of unreported (18.07% cumulative)
 Allocated at
   replace_malloc (/home/sywu/work/mozilla-central/memory/replace/dmd/DMD.cpp:1245) 0x1bcbcf1a
   _PR_Getfd (/home/sywu/work/mozilla-central/nsprpub/pr/src/io/prfdcach.c:113) 0x1a3ce3ac
   pt_SetMethods (/home/sywu/work/mozilla-central/nsprpub/pr/src/pthreads/ptio.c:3305) 0x1a3e8545
   PR_OpenFile (/home/sywu/work/mozilla-central/nsprpub/pr/src/pthreads/ptio.c:3582) 0x1a3e8be5
   do_create (/home/sywu/work/mozilla-central/xpcom/io/nsLocalFileUnix.cpp:429) 0x159b5a9e
   nsLocalFile::CreateAndKeepOpen(unsigned int, int, unsigned int, PRFileDesc**) (/home/sywu/work/mozilla-central/xpcom/io/nsLocalFileUnix.cpp:451) 0x159b7519
   nsLocalFile::Create(unsigned int, unsigned int) (/home/sywu/work/mozilla-central/xpcom/io/nsLocalFileUnix.cpp:498) 0x159b75b7
   nsLocalFile::CreateUnique(unsigned int, unsigned int) (/home/sywu/work/mozilla-central/xpcom/io/nsLocalFileCommon.cpp:79) 0x159bd15f
   nsDownloader::OnStartRequest(nsIRequest*, nsISupports*) (/home/sywu/work/mozilla-central/netwerk/base/src/nsDownloader.cpp:58) 0x15a28467
   mozilla::net::nsHttpChannel::CallOnStartRequest() (/home/sywu/work/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:922) 0x15ae3818
   mozilla::net::nsHttpChannel::ContinueOnStartRequest2(tag_nsresult) (/home/sywu/work/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:5085) 0x15ae40d6
   mozilla::net::nsHttpChannel::OnStartRequest(nsIRequest*, nsISupports*) (/home/sywu/work/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:5057) 0x15ae653a
   mozilla::ReentrantMonitor::Enter() (/home/sywu/work/mozilla-central/obj-x86_64-unknown-linux-gnu/netwerk/base/src/../../../dist/include/mozilla/ReentrantMonitor.h:74) 0x15a2d88c
   nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (/home/sywu/work/mozilla-central/netwerk/base/src/nsInputStreamPump.cpp:433) 0x15a3036e
   nsCOMPtr<nsIInputStreamCallback>::operator=(nsIInputStreamCallback*) (/home/sywu/work/mozilla-central/obj-x86_64-unknown-linux-gnu/xpcom/io/../../dist/include/nsCOMPtr.h:674) 0x159c5a06
   nsThread::ProcessNextEvent(bool, bool*) (/home/sywu/work/mozilla-central/xpcom/threads/nsThread.cpp:770) 0x159d15a6
   NS_ProcessNextEvent(nsIThread*, bool) (/home/sywu/work/mozilla-central/xpcom/glue/nsThreadUtils.cpp:265) 0x159e64e8
   mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (/home/sywu/work/mozilla-central/ipc/glue/MessagePump.cpp:100) 0x15bc5a84
   ~AutoRunState (/home/sywu/work/mozilla-central/ipc/chromium/src/base/message_loop.cc:504) 0x15bad259
   nsBaseAppShell::Run() (/home/sywu/work/mozilla-central/widget/xpwidgets/nsBaseAppShell.cpp:166) 0x166119eb
   nsAppStartup::Run() (/home/sywu/work/mozilla-central/toolkit/components/startup/nsAppStartup.cpp:279) 0x16d907d8
   XREMain::XRE_mainRun() (/home/sywu/work/mozilla-central/toolkit/xre/nsAppRunner.cpp:4014) 0x16d2bcb9
   XREMain::XRE_main(int, char**, nsXREAppData const*) (/home/sywu/work/mozilla-central/toolkit/xre/nsAppRunner.cpp:4084) 0x16d2befe
   XRE_main (/home/sywu/work/mozilla-central/toolkit/xre/nsAppRunner.cpp:4298) 0x16d2c127

Comment 17

[Nathan Froyd [:froydnj]]

Looks like:

- nsDownloader never explicitly closes the file that it opens; and
- nsLocalFile doesn't do so in its destructor.

...and we leak the file.

Comment 18

[Nathan Froyd [:froydnj]]

Hm, no, that's not quite right either.  What is going on here?

Comment 19

[Nicholas Nethercote [inactive]]

> Perhaps that's just due to DMD sampling?

Very likely -- DMD samples at a granularity of 4093 bytes by default. You can run with DMD='--sample-below=1' for full precision.

Comment 20

[Shian-Yow Wu [:swu]]

Attachment: DMD report (release build with new cache, and --sample-below=1)

Attached is the DMD report with DMD='--sample-below=1', and now it seems to be correct.

Below is the #1 unreported record after 30000 iterations.

Unreported {
  29,993 blocks in heap block record 1 of 26,533
  1,439,664 bytes (1,439,664 requested / 0 slop)
  2.93% of the heap (2.93% cumulative)
  7.10% of unreported (7.10% cumulative)
  Allocated at { 
    replace_malloc (/home/sywu/work/mozilla-central/memory/replace/dmd/DMD.cpp:1245) 0x7a54f200
    _PR_Getfd (/home/sywu/work/mozilla-central/nsprpub/pr/src/io/prfdcach.c:110) 0x78cce39a
    pt_SetMethods (/home/sywu/work/mozilla-central/nsprpub/pr/src/pthreads/ptio.c:3305) 0x78ce8545
    PR_OpenFile (/home/sywu/work/mozilla-central/nsprpub/pr/src/pthreads/ptio.c:3582) 0x78ce8be5
    do_create (/home/sywu/work/mozilla-central/xpcom/io/nsLocalFileUnix.cpp:429) 0x7429ecf6 
    nsLocalFile::CreateAndKeepOpen(unsigned int, int, unsigned int, PRFileDesc**) (/home/sywu/work/mozilla-central/xpcom/io/nsLocalFileUnix.cpp:451) 0x742a0771
    nsLocalFile::Create(unsigned int, unsigned int) (/home/sywu/work/mozilla-central/xpcom/io/nsLocalFileUnix.cpp:498) 0x742a080f
    nsLocalFile::CreateUnique(unsigned int, unsigned int) (/home/sywu/work/mozilla-central/xpcom/io/nsLocalFileCommon.cpp:79) 0x742a63d9
    nsDownloader::OnStartRequest(nsIRequest*, nsISupports*) (/home/sywu/work/mozilla-central/netwerk/base/src/nsDownloader.cpp:58) 0x7430fcb7
    mozilla::net::nsHttpChannel::CallOnStartRequest() (/home/sywu/work/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:921) 0x743c9f66
    mozilla::net::nsHttpChannel::ContinueOnStartRequest2(tag_nsresult) (/home/sywu/work/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:4991) 0x743ca824
    mozilla::net::nsHttpChannel::OnStartRequest(nsIRequest*, nsISupports*) (/home/sywu/work/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:4963) 0x743ccb40
    mozilla::ReentrantMonitor::Enter() (/home/sywu/work/mozilla-central/obj-x86_64-unknown-linux-gnu/netwerk/base/src/../../../dist/include/mozilla/ReentrantMonitor.h:74) 0x743150ca
    nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (/home/sywu/work/mozilla-central/netwerk/base/src/nsInputStreamPump.cpp:433) 0x74317ba6
    nsCOMPtr<nsIInputStreamCallback>::operator=(nsIInputStreamCallback*) (/home/sywu/work/mozilla-central/obj-x86_64-unknown-linux-gnu/xpcom/io/../../dist/include/nsCOMPtr.h:674) 0x742aec82
    nsThread::ProcessNextEvent(bool, bool*) (/home/sywu/work/mozilla-central/xpcom/threads/nsThread.cpp:770) 0x742ba9fc
    NS_ProcessNextEvent(nsIThread*, bool) (/home/sywu/work/mozilla-central/xpcom/glue/nsThreadUtils.cpp:265) 0x742d06d8
    mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (/home/sywu/work/mozilla-central/ipc/glue/MessagePump.cpp:100) 0x744aeb08
    ~AutoRunState (/home/sywu/work/mozilla-central/ipc/chromium/src/base/message_loop.cc:504) 0x744962e5
    nsBaseAppShell::Run() (/home/sywu/work/mozilla-central/widget/xpwidgets/nsBaseAppShell.cpp:166) 0x74f43537
    nsAppStartup::Run() (/home/sywu/work/mozilla-central/toolkit/components/startup/nsAppStartup.cpp:279) 0x75677a48
    XREMain::XRE_mainRun() (/home/sywu/work/mozilla-central/toolkit/xre/nsAppRunner.cpp:4014) 0x756a5145
    XREMain::XRE_main(int, char**, nsXREAppData const*) (/home/sywu/work/mozilla-central/toolkit/xre/nsAppRunner.cpp:4084) 0x756a538a
    XRE_main (/home/sywu/work/mozilla-central/toolkit/xre/nsAppRunner.cpp:4298) 0x756a55b3
  }
}

Comment 21

[Shian-Yow Wu [:swu]]

(In reply to Nicholas Nethercote [:njn] from comment #19)
> > Perhaps that's just due to DMD sampling?
> 
> Very likely -- DMD samples at a granularity of 4093 bytes by default. You
> can run with DMD='--sample-below=1' for full precision.

Mochitest doesn't support passing DMD options like this.  Filed Bug 1046011 for it.

Comment 22

[Shian-Yow Wu [:swu]]

(In reply to Shian-Yow Wu [:swu] from comment #20)
> Below is the #1 unreported record after 30000 iterations.
> 
> Unreported {
>   29,993 blocks in heap block record 1 of 26,533
>   1,439,664 bytes (1,439,664 requested / 0 slop)

1439664 / 29993 = 48

Comment 23

[Nicholas Nethercote [inactive]]

Removing the tag; tracking bug 573192 should be enough.

Comment 24

[Wan-Teh Chang]

(In reply to Shian-Yow Wu [:swu] (away 8/7 ~ 8/8) from comment #22)
> (In reply to Shian-Yow Wu [:swu] from comment #20)
> > Below is the #1 unreported record after 30000 iterations.
> > 
> > Unreported {
> >   29,993 blocks in heap block record 1 of 26,533
> >   1,439,664 bytes (1,439,664 requested / 0 slop)
> 
> 1439664 / 29993 = 48

The size of PRFileDesc and PRFilePrivate on 32-bit Linux should be 52 bytes
total (24 bytes and 28 bytes each), so this is off by 4 bytes but is close.

Does this mean this mochitest test opens 29,993 files consecutively before
it closes any of the files?

Comment 25

[Shian-Yow Wu [:swu]]

(In reply to Wan-Teh Chang from comment #24)
> (In reply to Shian-Yow Wu [:swu] (away 8/7 ~ 8/8) from comment #22)
> > (In reply to Shian-Yow Wu [:swu] from comment #20)
> > > Below is the #1 unreported record after 30000 iterations.
> > > 
> > > Unreported {
> > >   29,993 blocks in heap block record 1 of 26,533
> > >   1,439,664 bytes (1,439,664 requested / 0 slop)
> > 
> > 1439664 / 29993 = 48
> 
> The size of PRFileDesc and PRFilePrivate on 32-bit Linux should be 52 bytes
> total (24 bytes and 28 bytes each), so this is off by 4 bytes but is close.
> 
> Does this mean this mochitest test opens 29,993 files consecutively before
> it closes any of the files?

The file been created in each iteration was a tmp file in nsDownloader::OnStartRequest()
http://dxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsDownloader.cpp#57

An nsIOutputStream mSink then held the file descriptor of this tmp file and was closed
in nsDownloader::OnStopRequest()
http://dxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsDownloader.cpp#80

After each iteration, the tmp file was removed in the destructor nsDownloader::~nsDownloader()
http://dxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsDownloader.cpp#23

Comment 26

[Nathan Froyd [:froydnj]]

(In reply to Shian-Yow Wu [:swu] from comment #12)
> (In reply to Nathan Froyd (:froydnj) from comment #10)
> > Anyway, I notice that the log also shows the allocations coming from the
> > original networking cache, rather than the new networking cache, which seems
> > odd.  Shian-Yow, were these measurements taken with a recent build?  Do you
> > have the new networking cache disabled?
> 
> It was measured with m-c build within 2 weeks, and with the follwoing two
> options, no specific options related to networking cache.
>   --enable-debug
>   --enable-dmd

It's possible that I'm reading things incorrectly, but it looks like passing --enable-debug to the toplevel configure would pass down --enable-debug to NSPR, which would active these pieces of code:

http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/io/prfdcach.c#239
http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/io/prfdcach.c#137

The first part, in particular, ought to be limiting the FD cache to a reasonable size, so we should not be seeing unbounded growth.

Comment 27

[Shian-Yow Wu [:swu]]

(In reply to Nathan Froyd (:froydnj) from comment #26)
> (In reply to Shian-Yow Wu [:swu] from comment #12)
> > (In reply to Nathan Froyd (:froydnj) from comment #10)
> > > Anyway, I notice that the log also shows the allocations coming from the
> > > original networking cache, rather than the new networking cache, which seems
> > > odd.  Shian-Yow, were these measurements taken with a recent build?  Do you
> > > have the new networking cache disabled?
> > 
> > It was measured with m-c build within 2 weeks, and with the follwoing two
> > options, no specific options related to networking cache.
> >   --enable-debug
> >   --enable-dmd
> 
> It's possible that I'm reading things incorrectly, but it looks like passing
> --enable-debug to the toplevel configure would pass down --enable-debug to
> NSPR, which would active these pieces of code:
> 
> http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/io/prfdcach.
> c#239
> http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/io/prfdcach.
> c#137
> 
> The first part, in particular, ought to be limiting the FD cache to a
> reasonable size, so we should not be seeing unbounded growth.

The DMD log in comment 1 is measured with debug build, and log in comment 20 is measured with release build.

When I tested again by yesterday's m-c code with debug build, the memory allocation growth related to FD cache stopped at a certain boundary.  And in debug build, there is no more massive leakage from deadlock detector as bug 1027921 was resolved.

Comment 28

[Michal Novotny [:michal]]

Looks like problem in nsDownloader, not in the cache.

Comment 29

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 30

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258