Heap-unclassified keeps increasing in array buffer transfer mochitest

NEW
Unassigned

Status

()

Core
Networking
P3
normal
3 years ago
2 months ago

People

(Reporter: swu, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog])

Attachments

(5 attachments)

(Reporter)

Description

3 years ago
+++ 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.
(Reporter)

Comment 1

3 years ago
Created attachment 8457773 [details]
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%)
(Reporter)

Comment 2

3 years ago
Another major part of unreported heap is coming from DOM worker.
(Reporter)

Updated

3 years ago
Depends on: 1040592
(Reporter)

Comment 3

3 years ago
Created attachment 8458469 [details] [diff] [review]
Test case to reproduce
(Reporter)

Comment 4

3 years ago
(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.
(Reporter)

Updated

3 years ago
No longer depends on: 1037358
(Reporter)

Comment 5

3 years ago
Per bug 1040592 comment 4, a large of proportion of memory is being used in the deadlock detector, including cache and workers.
(Reporter)

Updated

3 years ago
Depends on: 1027921
No longer depends on: 1040592
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
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?
Flags: needinfo?(honzab.moz)
The NSPR thing is still an issue, so if you don't want to use this bug for that please file another.
(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?
Flags: needinfo?(honzab.moz)
(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?
Flags: needinfo?(swu)
Depends on: 573192
Turns out we've known about the busted NSPR caching for four years: bug 573192.
(Reporter)

Comment 12

3 years ago
(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
Flags: needinfo?(swu)
(Reporter)

Comment 13

3 years ago
Created attachment 8461343 [details]
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.
For some reason your FF runs with the old cache. Did you use a new profile?
(Reporter)

Comment 15

3 years ago
Created attachment 8461425 [details]
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
(Reporter)

Comment 16

3 years ago
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
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.
Hm, no, that's not quite right either.  What is going on here?
> 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.
(Reporter)

Comment 20

3 years ago
Created attachment 8464479 [details]
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
  }
}
(Reporter)

Comment 21

3 years ago
(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.
(Reporter)

Comment 22

3 years ago
(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
Removing the tag; tracking bug 573192 should be enough.
Whiteboard: [MemShrink]

Comment 24

3 years ago
(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?
(Reporter)

Comment 25

3 years ago
(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
(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.
(Reporter)

Comment 27

3 years ago
(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.
Whiteboard: [necko-backlog]
Looks like problem in nsDownloader, not in the cache.
Component: Networking: Cache → Networking
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.