805023 - Thunderbird about:memory memory reporter can be inaccurate for maildb - overreporting folder memory usage

Status: NEW

(MailNews Core :: Database, defect)

Description

[WaltS48 [:walts48]]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20121017073013

Steps to reproduce:

Installed Thunderbird 17.0
Installed Lightning 1.9b2
Ran Thunderbird with only that extension
Create at least 3 calendars (I have five)
Go to about:support > about:memory


Actual results:

This warning is displayed:

WARNING: the following values are negative or unreasonably large.
 explicit/storage/sqlite/(10 tiny)/other
This indicates a defect in one or more memory reporters.  The invalid values are highlighted.

Negative value is 

├────6.71 MB (03.52%) -- storage/sqlite
  └──1.59 MB (00.83%) -- (10 tiny)
    └──-1.65 MB (-0.87%) ── other [?!]


Expected results:

No warning message should appear

Comment 1

[Paul Silaghi, QA [:pauly]]

I reproduced the issue on Thunderbird 17b3 with Lightning 1.9 on Win 7 x64.

Comment 2

[:aceman]

The problem is, TB 17 is on gecko 17, so these problems may already be fixed by the memshrink team on newer gecko versions.

Somebody would need to confirm this problem still happens on TB 22+.

Comment 3

[WaltS48 [:walts48]]

Still occurring on TB 23.0a1 with Lightning 2.5a1, as originally stated in the bug report.

I'm going to try with a new profile since there is a new hiccup of the Trash calendar still appearing after I removed it, and restarted TB.

Comment 4

[Wayne Mery (:wsmwk)]

I see negative using 22.0a1 (2013-04-01) without lightning

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #4)
> I see negative using 22.0a1 (2013-04-01) without lightning

...for heap-unclassified

─-588.15 MB (-434.04%) -- (16 tiny) [?!]
   ├─────1.20 MB (00.89%) ── xpti-working-set
   ├─────1.10 MB (00.81%) ++ workers/workers()/worker(resource:///modules/attachmentChecker.js, 0x74fb400)
   ├─────0.87 MB (00.65%) ── xpconnect
   ├─────0.85 MB (00.62%) ── atom-tables
   ├─────0.43 MB (00.32%) ++ images
   ├─────0.33 MB (00.24%) ++ startup-cache
   ├─────0.31 MB (00.23%) ── preferences
   ├─────0.28 MB (00.21%) ++ xpcom
   ├─────0.27 MB (00.20%) ++ cycle-collector
   ├─────0.23 MB (00.17%) ++ layout
   ├─────0.12 MB (00.09%) ── script-namespace-manager
   ├─────0.09 MB (00.07%) ── dom/event-listener-managers-hash
   ├─────0.06 MB (00.05%) ++ network
   ├─────0.02 MB (00.01%) ── telemetry
   ├─────0.00 MB (00.00%) ── history-links-hashtable
   └──-594.32 MB (-438.60%) ── heap-unclassified [?!]

Comment 6

[Andrew McCreight [:mccr8]]

You should include the largest thing, too.  heap-unclassified is simply (total allocated memory - the sum of reported memory), so the question is which memory reporter is overreporting by hundreds of MBs.

Comment 7

[Wayne Mery (:wsmwk)]

Attachment: about:verbose

Comment 8

[Andrew McCreight [:mccr8]]

Okay, it looks like maildb is wildly overcounting, so somebody should either look at the memory reporter for that, or figure out how to get DMD running for Thunderbird.  DMD will tell you about double counting, but may be hard to get running, I'm not sure.

A couple of common causes for overcounting are using a counter-based approach to memory management (where the counter has gone wrong), or double counting (if some data structure if owned by multiple things, and each counts the usage of the data structure).

Comment 9

[Andrew McCreight [:mccr8]]

I moved this over to MailNews:Database, because it is presumably an error with code there somehow.

Comment 10

[:aceman]

I think it was said today, that jcranmer created the maildb reporter.

Comment 12

[Nicholas Nethercote [inactive]]

More precisely, "heap-unclassified" is "heap-allocated" minus all the individual heap measurements (which is most of them;  comparatively few are non-heap).  In the attachment, "heap-allocated" is 136,389,198 B, so as mccr8 says, something is overcounting badly.

Comment 13

[Wayne Mery (:wsmwk)]

my figures are now mostly unreliable

├──1,141.80 MB (631.29%) -- maildb [?!]
│  ├────585.35 MB (323.63%) ── database(imap://[e-mail]/Moz) [?!]
│  ├────197.79 MB (109.36%) ── database(imap://[e-mail]/INBOX) [?!]
│  ├────194.72 MB (107.66%) ── database(imap://[e-mail]/INBOX) [?!]
│  ├─────86.92 MB (48.06%) ── database(imap://[e-mail]/moz-lxmac/moz-FF)
│  ├─────48.23 MB (26.66%) ── database(imap://[e-mail]/INBOX)

Comment 14

[Joshua Cranmer [:jcranmer]]

(In reply to Wayne Mery (:wsmwk) from comment #13)
> ├──1,141.80 MB (631.29%) -- maildb [?!]
> │  ├────585.35 MB (323.63%) ── database(imap://[e-mail]/Moz)
> [?!]
> │  ├────197.79 MB (109.36%) ── database(imap://[e-mail]/INBOX)
> [?!]
> │  ├────194.72 MB (107.66%) ──
> database(imap://[e-mail]/INBOX) [?!]
> │  ├─────86.92 MB (48.06%) ──
> database(imap://[e-mail]/moz-lxmac/moz-FF)
> │  ├─────48.23 MB (26.66%) ──
> database(imap://[e-mail]/INBOX)

This is strongly evocative of the idea that we're not properly recording frees of the mork database (mismatched allocators?!). A MOZ_DMD report would be very useful here... maybe we could get that by building TB with a CXXFLAGS=-DMOZ_DMD=1 ?

Comment 15

[:aceman]

Wayne, but when you were reporting the numbers, did you check what the operating system task manager reported about TB memory usage? Or did you just go by the numbers in about:memory ?

Comment 16

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #15)
> Wayne, but when you were reporting the numbers, did you check what the
> operating system task manager reported about TB memory usage? 

yes, most certainly. I have no memory usage problems. my memory usage is "normal", typically in the range of 150-300MB.

Comment 17

[Wayne Mery (:wsmwk)]

(In reply to Joshua Cranmer [:jcranmer] from comment #14)
> This is strongly evocative of the idea that we're not properly recording
> frees of the mork database (mismatched allocators?!). A MOZ_DMD report would
> be very useful here... maybe we could get that by building TB with a
> CXXFLAGS=-DMOZ_DMD=1 ?

standard8, should we want CXXFLAGS=-DMOZ_DMD=1 for nightly builds?  For all builds?  Or just self built/try builds?

Comment 18

[Wayne Mery (:wsmwk)]

jcranmer correct me on IRC - the path would be  --enable-dmd and not CXXFLAGS

xref Bug 823641 - Enable Dark Matter Detector on Daily builds

Comment 19

[Mark Banner (:standard8)]

We should just follow what FF does.

Comment 20

[Wayne Mery (:wsmwk)]

In that case, can someone spin a try build with --enable-dmd ?
Several of us can use it.

Comment 21

[Wayne Mery (:wsmwk)]

From prior Thunderbird meeting ...

"jcranmer: Someone needs to do something with dmd (dark-matter-detector) to determine what's going on there [in this bug]."

Comment 22

[Petr Vones]

TB 24.2.0

──-4.91 MB (-5.23%) -- (14 tiny) [?!]
   ├───0.91 MB (00.97%) ── atom-tables
   ├───0.88 MB (00.93%) ++ gfx
   ├───0.66 MB (00.70%) ── xpconnect
   ├───0.28 MB (00.30%) ++ xpcom
   ├───0.23 MB (00.24%) ++ layout
   ├───0.22 MB (00.24%) ── preferences
   ├───0.12 MB (00.13%) ── script-namespace-manager
   ├───0.09 MB (00.10%) ── dom/event-listener-managers-hash
   ├───0.05 MB (00.05%) ++ cycle-collector
   ├───0.04 MB (00.04%) ── network/disk-cache
   ├───0.02 MB (00.02%) ── telemetry
   ├───0.00 MB (00.00%) ── history-links-hashtable
   ├───0.00 MB (00.00%) ── spell-check
   └──-8.41 MB (-8.96%) ── heap-unclassified [?!]

Comment 23

[WaltS48 [:walts48]]

Attachment: memory-report.json.gz

Using Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Thunderbird/31.0a1 BuildID:20140417030201

I noticed the memory warning cleared up when I clicked Minimize memory usage, but it returns on each restart of Thunderbird. Does not clear up using Thunderbird 24.4.0.

Adding some memory attachments, hoping they will help.

Comment 24

[WaltS48 [:walts48]]

Attachment: memory-report.json1.gz

Comment 25

[WaltS48 [:walts48]]

Attachment: cc-edges.3875.1397745167.log

Comment 26

[Wayne Mery (:wsmwk)]

could someone toss a windows try build for me with --enable-dmd  ?

Comment 27

[Mike Conley (:mconley) (:⚙️)]

My try build here fails to build: https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=728a958cde6d

:/ I'll try hand-rolling you one then... *sigh*

Comment 28

[Wayne Mery (:wsmwk)]

(In reply to Mike Conley (:mconley) from comment #27)
> My try build here fails to build:
> https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=728a958cde6d
> 
> :/ I'll try hand-rolling you one then... *sigh*

according the the log ...

The error occurred while processing the following file:
    c:/builds/moz2_slave/tb-try-c-cen-w32-0000000000000/build/ldap/xpcom/moz.build

The error was triggered on line 6 of this file:
    PARALLEL_DIRS += [

The underlying problem is an attempt to read a reserved UPPERCASE variable that does not exist.

The variable read causing the error is:
    PARALLEL_DIRS

Please use the DIRS variable instead.

Comment 29

[Kent James (:rkent)]

Clearing out hold requests, I tried to build with DMD locally, and I failed with some sort of out of memory during compile (on Windows). I really don't know anything about DMD so I don't think I am the correct person to pursue this.

Comment 30

[Phoenix]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #26)
> could someone toss a windows try build for me with --enable-dmd  ?
Done, please check
http://www.cs.iptcom.net/tmp/thunderbird-40.0a1.en-US.win32.installer.exe

Comment 31

[Wayne Mery (:wsmwk)]

innaccurate

Comment 32

[Carl]

Attachment: memory-report,2016-03-03,Carl.json.gz

Providing an example of how this very long outstanding bug is still in existence. I've attached an anonymized memory report which corresponds to Sysinternals Process Explorer telling me that Thunderbird is using 609.5K Private Bytes and 618.7K Working Set. These values are much higher than they used to be (see also bug report 1219334). Memory report GUI includes this:

  WARNING: the following values are negative or unreasonably large.

      explicit/maildb/database(<anonymized>)
      explicit/(20 tiny)
      explicit/(20 tiny)/heap-unclassified 

  This indicates a defect in one or more memory reporters. The invalid values are highlighted.

  Explicit Allocations

  518.88 MB (100.0%) -- explicit
  ├──1,307.03 MB (251.89%) ── maildb/database(<anonymized>) [?!] [10]
  ├──275.95 MB (53.18%) -- window-objects
  ...
  └──-1,200.52 MB (-231.37%) -- (20 tiny) [?!]
     ├───────4.01 MB (00.77%) ++ atom-tables
     ├───────3.69 MB (00.71%) ++ workers/workers(chrome)
     ├───────3.39 MB (00.65%) ++ cycle-collector
     ├───────3.02 MB (00.58%) ── spell-check
     ├───────3.00 MB (00.58%) ++ images
     ├───────3.00 MB (00.58%) ── dom/event-listener-managers-hash
     ├───────2.44 MB (00.47%) ++ gfx
     ├───────1.16 MB (00.22%) ── xpti-working-set
     ├───────0.41 MB (00.08%) ── preferences
     ├───────0.28 MB (00.05%) ++ layout
     ├───────0.27 MB (00.05%) ++ xpcom
     ├───────0.19 MB (00.04%) ── icu
     ├───────0.17 MB (00.03%) ++ startup-cache
     ├───────0.10 MB (00.02%) ── script-namespace-manager
     ├───────0.05 MB (00.01%) ++ network
     ├───────0.03 MB (00.01%) ── telemetry
     ├───────0.00 MB (00.00%) ── cookie-service
     ├───────0.00 MB (00.00%) ── history-links-hashtable
     ├───────0.00 MB (00.00%) ++ media
     └──-1,225.73 MB (-236.23%) ── heap-unclassified [?!]

This is with Thunderbird 38.6.0 on WinXP-SP3.