Closed Bug 942225 Opened 11 years ago Closed 9 years ago

Frequent |leakcheck | 2xxx bytes leaked (CompositorChild, CondVar, Mutex, PCompositorChild, PLayerTransactionChild, ...)| after OSX test hangs/crashes

Categories

(Core :: Graphics: Layers, defect)

Product:
Core
Component:
Graphics: Layers
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: RyanVM, Assigned: nical)

Details

(Keywords: memory-leak)

I assume this is OMTC-related. We often see these leaks on TBPL when there's a test crash or hang that's force-killed. Would be nice if someone could look at it to help reduce the noise. Presumably something's not being cleaned up at the right time? The exact number of bytes varies, but it's always in the high 2000's. https://tbpl.mozilla.org/php/getParsedLog.php?id=30965355&tree=Mozilla-Inbound Rev4 MacOSX Snow Leopard 10.6 mozilla-inbound debug test mochitest-browser-chrome on 2013-11-22 07:49:22 PST for push c26abb79ec82 slave: talos-r4-snow-066 09:22:18 INFO - == BloatView: ALL (cumulative) LEAK AND BLOAT STATISTICS, tab process 951 09:22:18 INFO - |<----------------Class--------------->|<-----Bytes------>|<----------------Objects---------------->|<--------------References-------------->| 09:22:18 INFO - Per-Inst Leaked Total Rem Mean StdDev Total Rem Mean StdDev 09:22:18 INFO - 0 TOTAL 43 2968 47573 17 ( 1339.44 +/- 1418.92) 94326 3 ( 1460.50 +/- 2764.68) 09:22:18 INFO - 19 CompositorChild 728 1456 2 2 ( 1.50 +/- 0.71) 1 1 ( 1.00 +/- 0.00) 09:22:18 INFO - 20 CondVar 32 32 8 1 ( 4.27 +/- 2.25) 0 0 ( 0.00 +/- 0.00) 09:22:18 INFO - 86 Mutex 24 24 105 1 ( 49.03 +/- 26.00) 0 0 ( 0.00 +/- 0.00) 09:22:18 INFO - 93 PCompositorChild 696 696 1 1 ( 1.00 +/- 0.00) 0 0 ( 0.00 +/- 0.00) 09:22:18 INFO - 102 PLayerTransactionChild 72 144 2 2 ( 1.50 +/- 0.71) 0 0 ( 0.00 +/- 0.00) 09:22:18 INFO - 123 RefCountedMonitor 64 64 3 1 ( 1.80 +/- 0.84) 3 1 ( 1.80 +/- 0.84) 09:22:18 INFO - 124 RefCountedTask 16 16 3 1 ( 1.80 +/- 0.84) 74 1 ( 14.53 +/- 10.47) 09:22:18 INFO - 176 ipc::MessageChannel 480 480 3 1 ( 1.80 +/- 0.84) 0 0 ( 0.00 +/- 0.00) 09:22:18 INFO - 456 nsTArray_base 8 56 12515 7 ( 2584.28 +/- 1178.51) 0 0 ( 0.00 +/- 0.00) 09:22:18 INFO - nsTraceRefcntImpl::DumpStatistics: 514 entries 09:22:18 INFO - TEST-INFO | leakcheck | leaked 2 CompositorChild (1456 bytes) 09:22:18 INFO - TEST-INFO | leakcheck | leaked 1 CondVar (32 bytes) 09:22:18 INFO - TEST-INFO | leakcheck | leaked 1 Mutex (24 bytes) 09:22:18 INFO - TEST-INFO | leakcheck | leaked 1 PCompositorChild (696 bytes) 09:22:18 INFO - TEST-INFO | leakcheck | leaked 2 PLayerTransactionChild (144 bytes) 09:22:18 INFO - TEST-INFO | leakcheck | leaked 1 RefCountedMonitor (64 bytes) 09:22:18 INFO - TEST-INFO | leakcheck | leaked 1 RefCountedTask (16 bytes) 09:22:18 INFO - TEST-INFO | leakcheck | leaked 1 ipc::MessageChannel (480 bytes) 09:22:18 INFO - TEST-INFO | leakcheck | leaked 7 nsTArray_base (56 bytes) 09:22:18 WARNING - TEST-UNEXPECTED-FAIL | leakcheck | 2968 bytes leaked (CompositorChild, CondVar, Mutex, PCompositorChild, PLayerTransactionChild, ...)
Component: Graphics → Graphics: Layers
This is basically the only mochitest leak we see on a regular basis still. Can we please find someone with time to look into it?
Flags: needinfo?(milan)
Is this 10.6 only, or showing up as 10.6 because that's where we run the tests? Mind you, even if only 10.6, that could be timing related, rather than OS version.
I think it's 10.6-only, but that may also be a consequence of the fact that mochitests are far more timeout-prone (and therefore likely to be force-killed) than they are on 10.8.
I don't know if Matt can look at it now; I'll leave myself as need info for train 31.
Matt, Nicolas, thought on the subject?
Flags: needinfo?(nical.bugzilla)
Flags: needinfo?(milan)
Flags: needinfo?(matt.woodrow)
PCompositorChild and some other protocols (PImagrBridge, PLayerTransaction, etc.) get destroyed in Gecko's shutdown sequence, so I am not surprised that they show up as leaks if we kill firefox before running the proper shutdown sequence.
Flags: needinfo?(nical.bugzilla)
Ryan, I'm not sure we can do anything practical here, based on comment 6. Shutdown sequence is what cleans these, if we kill it, it won't get run. Or did I misunderstand what's happening? The test times out, we kill it, we get the leaks showing?
Flags: needinfo?(matt.woodrow)
Sounds that way. I do wonder why this is the only such leak we see under these conditions, though.
That is an excellent question. I'm going to assign to :nical to take a look as a background task.
Assignee: nobody → nical.bugzilla
This went away at some point.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.