1476405 - Report stack sizes for non-nsThread threads

Status: RESOLVED FIXED

(Core :: XPCOM, enhancement)

Description

[Kris Maglione [:kmag]]

The thread stack reporter added in bug 1475899 currently only reports on native nsThread threads. That should cover the majority of our threads, but it leaves out some important ones, like JS helper threads and Chromium IPC threads.

Fortunately, nsThread is already designed to transparently create wrappers for externally-created threads. So to add reporters for them, we should only need to make sure we create wrappers for them, add those wrappers to the thread list, and initialize them with the stack base/size and thread ID information that the reporters rely on.

Comment 1

[Kris Maglione [:kmag]]

Attachment: Bug 1476405: Part 1 - Allow enumerating non-native nsThread threads.

Review commit: https://reviewboard.mozilla.org/r/258262/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/258262/

Comment 2

[Kris Maglione [:kmag]]

Attachment: Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads.

Review commit: https://reviewboard.mozilla.org/r/258264/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/258264/

Comment 3

[Kris Maglione [:kmag]]

Attachment: Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads.

For ordinary JS helper threads, we can update names and create wrappers using
the existing thread profiler hooks, but we still need to update their default
stack sizes to avoid huge pages.

For the XPConnect JS Watchdog thread, we sometimes get a wrapper as it is, but
only sometimes. And we never use a reasonable stack size.

Review commit: https://reviewboard.mozilla.org/r/258266/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/258266/

Comment 4

[Kris Maglione [:kmag]]

Attachment: Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler.

This automatically gets us wrappers (and therefore memory statistics) for
Stylo threads, JS HelperThreads, and any other non-nsThread threads that we
already register with the profiler.

Review commit: https://reviewboard.mozilla.org/r/258268/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/258268/

Comment 5

[Kris Maglione [:kmag]]

Attachment: Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor.

BackgroundHangMonitor is a special snowflake, and uses PR_CreateThread
directly, for some reason.

Review commit: https://reviewboard.mozilla.org/r/258270/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/258270/

Comment 6

[Kris Maglione [:kmag]]

Attachment: Bug 1476405: Part 6 - Register AudioIPC threads with the profiler.

Presumably the Rust portion of this will have to land externally first and
then be imported, but I have no idea how or where to submit it.

Review commit: https://reviewboard.mozilla.org/r/258272/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/258272/

Comment 7

[Matthew Gregan [:kinetik]]

Comment on attachment 8993565 [details]
Bug 1476405: Part 6 - Register AudioIPC threads with the profiler.

https://reviewboard.mozilla.org/r/258272/#review265276

LGTM. The Rust AudioIPC stuff lives here: https://github.com/djg/audioipc-2

Comment 8

[Eric Rahm [:erahm]]

Comment on attachment 8993560 [details]
Bug 1476405: Part 1 - Allow enumerating non-native nsThread threads.

https://reviewboard.mozilla.org/r/258262/#review265498

::: xpcom/threads/nsThread.h:69
(Diff revision 1)
>  
>    // Initialize this as a wrapper for the current PRThread.
>    nsresult InitCurrentThread();
>  
> +private:
> +  void InitCommon();

Can you add a comment saying what this does, something like "Stores the thread ID and loads stack information"

Comment 9

[Eric Rahm [:erahm]]

Comment on attachment 8993561 [details]
Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads.

https://reviewboard.mozilla.org/r/258264/#review265500

Logically fine, but I'd like to move the `stack_size` change to another patch/bug.

::: ipc/chromium/src/base/platform_thread_posix.cc:128
(Diff revision 1)
>    if (!joinable) {
>      pthread_attr_setdetachstate(&attributes, PTHREAD_CREATE_DETACHED);
>    }
>  
> -  if (stack_size > 0)
> +  if (stack_size == 0)
> +    stack_size = nsIThreadManager::DEFAULT_STACK_SIZE;

This needs to be in a separate patch (or bug). For chromium threads we may really want the platform default, I'll defer to jld on that.

::: ipc/chromium/src/base/platform_thread_win.cc:58
(Diff revision 1)
>  // static
>  void PlatformThread::SetName(const char* name) {
> -#ifdef HAVE_SEH_EXCEPTIONS
> -  // The debugger needs to be around to catch the name in the exception.  If
> -  // there isn't a debugger, we are just needlessly throwing an exception.
> -  if (!::IsDebuggerPresent())
> +  // Using NS_SetCurrentThreadName, as opposed to using platform APIs directly,
> +  // also sets the thread name on the PRThread wrapper, and allows us to
> +  // retrieve it using PR_GetThreadName.
> +  NS_SetCurrentThreadName(name);

Note to other reviewers, NSPR does this [magic incantation](https://searchfox.org/mozilla-central/rev/8384a6519437f5eefbe522196f9ddf5c8b1d3fb4/nsprpub/pr/src/md/windows/w95thred.c#230-261) as well.

Comment 10

[Eric Rahm [:erahm]]

Comment on attachment 8993562 [details]
Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads.

https://reviewboard.mozilla.org/r/258266/#review265504

Looks good, super minor cleanup requests.

::: js/src/vm/HelperThreads.cpp:946
(Diff revision 1)
>      JSContext* cx = TlsContext.get();
>      return cx->helperThread() && cx->helperThread()->parseTask();
>  }
>  #endif
>  
> -static const uint32_t kDefaultHelperStackSize = 2048 * 1024;
> +static const uint32_t kDefaultHelperStackSize = 2040 * 1024;

nit: maybe do the minus 8k thing, and definitely add a note about the linux huge page stuff.

::: js/xpconnect/src/XPCJSContext.cpp:144
(Diff revision 1)
>              AutoLockWatchdog lock(this);
>  
>              // Gecko uses thread private for accounting and has to clean up at thread exit.
>              // Therefore, even though we don't have a return value from the watchdog, we need to
>              // join it on shutdown.
>              mThread = PR_CreateThread(PR_USER_THREAD, WatchdogMain, this,

Not something you should worry about, but couldn't this be an nsThread since it's living in xpconnect-land?

::: js/xpconnect/src/XPCJSContext.cpp:146
(Diff revision 1)
>              // Gecko uses thread private for accounting and has to clean up at thread exit.
>              // Therefore, even though we don't have a return value from the watchdog, we need to
>              // join it on shutdown.
>              mThread = PR_CreateThread(PR_USER_THREAD, WatchdogMain, this,
>                                        PR_PRIORITY_NORMAL, PR_GLOBAL_THREAD,
> -                                      PR_JOINABLE_THREAD, 0);
> +                                      PR_JOINABLE_THREAD, 32 * 1024);

nit: please move to a const, add a comment that the watchdog doesn't need a large stack.

::: js/xpconnect/src/XPCJSContext.cpp:475
(Diff revision 1)
>  
>  static void
>  WatchdogMain(void* arg)
>  {
>      AUTO_PROFILER_REGISTER_THREAD("JS Watchdog");
> +    Unused << NS_GetCurrentThread();

Nit: please add a comment about this registering with the thread manager.

Comment 11

[Eric Rahm [:erahm]]

Comment on attachment 8993563 [details]
Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler.

https://reviewboard.mozilla.org/r/258268/#review265508

::: commit-message-e16f0:5
(Diff revision 1)
> +Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler. r?erahm,mstange
> +
> +This automatically gets us wrappers (and therefore memory statistics) for
> +Stylo threads, JS HelperThreads, and any other non-nsThread threads that we
> +already register with the profiler.

Is that only if the profiler is enabled? Or do we still hit this code no matter what?

Comment 12

[Kris Maglione [:kmag]]

Comment on attachment 8993562 [details]
Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads.

https://reviewboard.mozilla.org/r/258266/#review265504

> Not something you should worry about, but couldn't this be an nsThread since it's living in xpconnect-land?

It could. I'm guessing they chose a PRThread because it just runs a single loop, and doesn't really need an event queue.

But I've been thinking about ways to get rid of these separate watchdog threads, and just have them use the Timer thread (and possibly a shared thread pool) instead, so I didn't want to make any major changes at this point.

Comment 13

[Kris Maglione [:kmag]]

Comment on attachment 8993563 [details]
Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler.

https://reviewboard.mozilla.org/r/258268/#review265508

> Is that only if the profiler is enabled? Or do we still hit this code no matter what?

We hit it no matter what

Comment 14

[Eric Rahm [:erahm]]

Comment on attachment 8993564 [details]
Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor.

https://reviewboard.mozilla.org/r/258270/#review265510

::: commit-message-67790:3
(Diff revision 1)
> +Bug 1476405: Part 5 - Create nsThread wrapper for BackgroundHangMonitor. r?erahm
> +
> +BackgroundHangMonitor is a special snowflake, and uses PR_CreateThread

We could file a followup to convert to `nsThread`, might be a good first bug.

::: toolkit/components/backgroundhangmonitor/BackgroundHangMonitor.cpp:72
(Diff revision 1)
>  private:
>    // Background hang monitor thread function
>    static void MonitorThread(void* aData)
>    {
>      AUTO_PROFILER_REGISTER_THREAD("BgHangMonitor");
> +    Unused << NS_GetCurrentThread();

nit: add comment

::: toolkit/components/backgroundhangmonitor/BackgroundHangMonitor.cpp:273
(Diff revision 1)
>    MonitorAutoLock autoLock(mLock);
>  
>    mHangMonitorThread = PR_CreateThread(
>      PR_USER_THREAD, MonitorThread, this,
> -    PR_PRIORITY_LOW, PR_GLOBAL_THREAD, PR_JOINABLE_THREAD, 0);
> +    PR_PRIORITY_LOW, PR_GLOBAL_THREAD, PR_JOINABLE_THREAD,
> +    nsIThreadManager::DEFAULT_STACK_SIZE);

nit: please update the commit to note this modifies the stack size.

Comment 15

[Kris Maglione [:kmag]]

Comment on attachment 8993564 [details]
Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor.

https://reviewboard.mozilla.org/r/258270/#review265510

> We could file a followup to convert to `nsThread`, might be a good first bug.

I was hoping to actually just get rid of this thread and use a timer instead.

Comment 16

[Kris Maglione [:kmag]]

Comment on attachment 8993561 [details]
Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads.

https://reviewboard.mozilla.org/r/258264/#review265500

> This needs to be in a separate patch (or bug). For chromium threads we may really want the platform default, I'll defer to jld on that.

Yeah, I was kind of on the fence about whether it needed a separate patch. I only realized it was a problem after I added the reporter and did a few runs, and eventually decided to just fold it into the existing patch.

Comment 17

[Kris Maglione [:kmag]]

Attachment: Bug 1476405: Part 2b - Use default thread size from nsIThreadManager in Linux PlatformThreads.

Review commit: https://reviewboard.mozilla.org/r/258480/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/258480/

Comment 18

[Kris Maglione [:kmag]]

Comment on attachment 8993560 [details]
Bug 1476405: Part 1 - Allow enumerating non-native nsThread threads.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/258262/diff/1-2/

Comment 19

[Kris Maglione [:kmag]]

Comment on attachment 8993561 [details]
Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/258264/diff/1-2/

Comment 20

[Kris Maglione [:kmag]]

Comment on attachment 8993562 [details]
Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/258266/diff/1-2/

Comment 21

[Kris Maglione [:kmag]]

Comment on attachment 8993563 [details]
Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/258268/diff/1-2/

Comment 22

[Kris Maglione [:kmag]]

Comment on attachment 8993564 [details]
Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/258270/diff/1-2/

Comment 23

[Kris Maglione [:kmag]]

Comment on attachment 8993565 [details]
Bug 1476405: Part 6 - Register AudioIPC threads with the profiler.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/258272/diff/1-2/

Comment 24

[Eric Rahm [:erahm]]

Comment on attachment 8993561 [details]
Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads.

https://reviewboard.mozilla.org/r/258264/#review265534

Comment 25

[Eric Rahm [:erahm]]

Comment on attachment 8993562 [details]
Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads.

https://reviewboard.mozilla.org/r/258266/#review265536

Comment 26

[Markus Stange [:mstange]]

Comment on attachment 8993563 [details]
Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler.

https://reviewboard.mozilla.org/r/258268/#review265840

Comment 27

[Markus Stange [:mstange]]

Comment on attachment 8993564 [details]
Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor.

https://reviewboard.mozilla.org/r/258270/#review265842

::: toolkit/components/backgroundhangmonitor/BackgroundHangMonitor.cpp:72
(Diff revision 2)
> +    // Create an nsThread wrapper for the thread and register it with the thread
> +    // manager.
> +    Unused << NS_GetCurrentThread();

Is this needed, given that the thread is already being registered with the profiler?

Comment 28

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Comment on attachment 8993561 [details]
Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads.

https://reviewboard.mozilla.org/r/258264/#review266216

Comment 29

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Comment on attachment 8993794 [details]
Bug 1476405: Part 2b - Use default thread size from nsIThreadManager in Linux PlatformThreads.

https://reviewboard.mozilla.org/r/258480/#review266218

I don't think IPC has any dependencies on using libpthread's default stack size in particular.  (And if we do, we should break them and find out what they are.)  Looks good.

Comment 30

[Kris Maglione [:kmag]]

Comment on attachment 8993564 [details]
Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor.

https://reviewboard.mozilla.org/r/258270/#review265842

> Is this needed, given that the thread is already being registered with the profiler?

Probably not. I wrote this part before I wrote the profiler part.

Comment 31

[Kris Maglione [:kmag]]

Attachment: Bug 1476405: Part 1 - Allow enumerating non-native nsThread threads. r=erahm

MozReview-Commit-ID: 1JKxWeejqzi

Comment 32

[Kris Maglione [:kmag]]

Attachment: Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads. r?erahm,tcampbell

For ordinary JS helper threads, we can update names and create wrappers using
the existing thread profiler hooks, but we still need to update their default
stack sizes to avoid huge pages.

For the XPConnect JS Watchdog thread, we sometimes get a wrapper as it is, but
only sometimes. And we never use a reasonable stack size.

MozReview-Commit-ID: EuR3gL5JATL

Comment 33

[Phabricator Automation]

Comment on attachment 8995261 [details]
Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads. r?erahm,tcampbell

Ted Campbell [:tcampbell] has approved the revision.

https://phabricator.services.mozilla.com/D2418

Comment 34

[Ted Campbell [:tcampbell]]

Comment on attachment 8993562 [details]
Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads.

(r+ on phabricator too. They seem to be the same patch)

Comment 35

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/06b8093ddc6a341b8be4ef2c4dca2188ada74296
Bug 1476405: Part 1 - Allow enumerating non-native nsThread threads. r=erahm

https://hg.mozilla.org/integration/mozilla-inbound/rev/d0ebb3aa8e0f0946eafc2e7cac4d5cbcf1694e2f
Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads. r=erahm,jld

https://hg.mozilla.org/integration/mozilla-inbound/rev/6c154f4d9dd93e3dac6045c3b8ead22702071fda
Bug 1476405: Part 2b - Use default thread size from nsIThreadManager in Linux PlatformThreads. r=jld

https://hg.mozilla.org/integration/mozilla-inbound/rev/f092a32a363911e58c71ed5d2e4bd92347437c7e
Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads. r=erahm,tcampbell

https://hg.mozilla.org/integration/mozilla-inbound/rev/b5b9d295545dff9c8f7aa5e5c0137afa24385eb2
Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler. r=erahm,mstange

https://hg.mozilla.org/integration/mozilla-inbound/rev/b2a99f50e642cc3dc41ab540e7639d2c39bbe75b
Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor. r=erahm

https://hg.mozilla.org/integration/mozilla-inbound/rev/6d18a8bd5ee351da1a0cdfaa63f49706a2f95ba3
Bug 1476405: Part 6 - Register AudioIPC threads with the profiler. r=kinetik

https://hg.mozilla.org/integration/mozilla-inbound/rev/cb7f7cc326875b2fd28d4a63101b07360a6606fd
Bug 1476405: Follow-up: Handle nsThread cleanup for threads that never shutdown. r=me

Comment 36

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4113d6fb3c1c74301f4ba5269a5218a5d649e532
Bug 1476405: Follow-up: Remove added assertion. r=bustage

Comment 37

[Cristina Coroiu [:ccoroiu]]

Backed out 9 changesets (bug 1476405) for causing leaks

Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/03c1386d08390bb8d983162e1181f7d5d5780788

Failure push: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=cb7f7cc326875b2fd28d4a63101b07360a6606fd

Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=190452549&repo=mozilla-inbound&lineNumber=2955

task 2018-07-27T05:35:49.742Z] 05:35:49     INFO - TEST-OK | devtools/server/tests/browser/browser_webextension_inspected_window.js | took 9913ms
[task 2018-07-27T05:35:49.787Z] 05:35:49     INFO - checking window state
[task 2018-07-27T05:35:51.876Z] 05:35:51     INFO - GECKO(2718) | Completed ShutdownLeaks collections in process 2790
[task 2018-07-27T05:35:51.876Z] 05:35:51     INFO - GECKO(2718) | Completed ShutdownLeaks collections in process 2860
[task 2018-07-27T05:35:51.965Z] 05:35:51     INFO - GECKO(2718) | Completed ShutdownLeaks collections in process 2929
[task 2018-07-27T05:35:51.972Z] 05:35:51     INFO - GECKO(2718) | Completed ShutdownLeaks collections in process 2825
[task 2018-07-27T05:35:52.069Z] 05:35:52     INFO - GECKO(2718) | Completed ShutdownLeaks collections in process 2891
[task 2018-07-27T05:35:52.569Z] 05:35:52     INFO - GECKO(2718) | Completed ShutdownLeaks collections in process 2718
[task 2018-07-27T05:35:52.570Z] 05:35:52     INFO - TEST-START | Shutdown
[task 2018-07-27T05:35:52.570Z] 05:35:52     INFO - Browser Chrome Test Summary
[task 2018-07-27T05:35:52.570Z] 05:35:52     INFO - Passed:  1047
[task 2018-07-27T05:35:52.571Z] 05:35:52     INFO - Failed:  0
[task 2018-07-27T05:35:52.571Z] 05:35:52     INFO - Todo:    0
[task 2018-07-27T05:35:52.572Z] 05:35:52     INFO - Mode:    e10s
[task 2018-07-27T05:35:52.572Z] 05:35:52     INFO - *** End BrowserChrome Test Results ***
[task 2018-07-27T05:35:52.791Z] 05:35:52     INFO - GECKO(2718) | ###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost
[task 2018-07-27T05:35:53.320Z] 05:35:53     INFO - GECKO(2718) | 1532669753318	Marionette	DEBUG	Received observer notification xpcom-will-shutdown
[task 2018-07-27T05:35:53.337Z] 05:35:53     INFO - GECKO(2718) | 1532669753326	Marionette	INFO	Stopped listening on port 2828
[task 2018-07-27T05:35:53.337Z] 05:35:53     INFO - GECKO(2718) | 1532669753329	Marionette	DEBUG	Remote service is inactive
[task 2018-07-27T05:35:55.759Z] 05:35:55     INFO - GECKO(2718) | -----------------------------------------------------
[task 2018-07-27T05:35:55.760Z] 05:35:55     INFO - GECKO(2718) | Suppressions used:
[task 2018-07-27T05:35:55.760Z] 05:35:55     INFO - GECKO(2718) |   count      bytes template
[task 2018-07-27T05:35:55.760Z] 05:35:55     INFO - GECKO(2718) |       1         40 libc.so
[task 2018-07-27T05:35:55.761Z] 05:35:55     INFO - GECKO(2718) |     636      20288 nsComponentManagerImpl
[task 2018-07-27T05:35:55.762Z] 05:35:55     INFO - GECKO(2718) |       6       1248 mozJSComponentLoader::LoadModule
[task 2018-07-27T05:35:55.764Z] 05:35:55     INFO - GECKO(2718) |     611      17713 libfontconfig.so
[task 2018-07-27T05:35:55.765Z] 05:35:55     INFO - GECKO(2718) |       1         29 libglib-2.0.so
[task 2018-07-27T05:35:55.766Z] 05:35:55     INFO - GECKO(2718) | -----------------------------------------------------
[task 2018-07-27T05:35:55.782Z] 05:35:55     INFO - GECKO(2718) | -----------------------------------------------------
[task 2018-07-27T05:35:55.784Z] 05:35:55     INFO - GECKO(2718) | Suppressions used:
[task 2018-07-27T05:35:55.785Z] 05:35:55     INFO - GECKO(2718) |   count      bytes template
[task 2018-07-27T05:35:55.787Z] 05:35:55     INFO - GECKO(2718) |     636      20288 nsComponentManagerImpl
[task 2018-07-27T05:35:55.788Z] 05:35:55     INFO - GECKO(2718) |       4        832 mozJSComponentLoader::LoadModule
[task 2018-07-27T05:35:55.789Z] 05:35:55     INFO - GECKO(2718) |     611      17713 libfontconfig.so
[task 2018-07-27T05:35:55.790Z] 05:35:55     INFO - GECKO(2718) |       1         29 libglib-2.0.so
[task 2018-07-27T05:35:55.791Z] 05:35:55     INFO - GECKO(2718) | -----------------------------------------------------
[task 2018-07-27T05:35:55.797Z] 05:35:55     INFO - GECKO(2718) | -----------------------------------------------------
[task 2018-07-27T05:35:55.798Z] 05:35:55     INFO - GECKO(2718) | Suppressions used:
[task 2018-07-27T05:35:55.799Z] 05:35:55     INFO - GECKO(2718) |   count      bytes template
[task 2018-07-27T05:35:55.800Z] 05:35:55     INFO - GECKO(2718) |     636      20288 nsComponentManagerImpl
[task 2018-07-27T05:35:55.812Z] 05:35:55     INFO - GECKO(2718) |       5       1040 mozJSComponentLoader::LoadModule
[task 2018-07-27T05:35:55.814Z] 05:35:55     INFO - GECKO(2718) |     611      17713 libfontconfig.so
[task 2018-07-27T05:35:55.815Z] 05:35:55     INFO - GECKO(2718) |       1         29 libglib-2.0.so
[task 2018-07-27T05:35:55.817Z] 05:35:55     INFO - GECKO(2718) | -----------------------------------------------------
[task 2018-07-27T05:35:55.817Z] 05:35:55     INFO - GECKO(2718) | -----------------------------------------------------
[task 2018-07-27T05:35:55.818Z] 05:35:55     INFO - GECKO(2718) | Suppressions used:
[task 2018-07-27T05:35:55.818Z] 05:35:55     INFO - GECKO(2718) |   count      bytes template
[task 2018-07-27T05:35:55.819Z] 05:35:55     INFO - GECKO(2718) |     636      20288 nsComponentManagerImpl
[task 2018-07-27T05:35:55.820Z] 05:35:55     INFO - GECKO(2718) |       5       1040 mozJSComponentLoader::LoadModule
[task 2018-07-27T05:35:55.820Z] 05:35:55     INFO - GECKO(2718) |     611      17713 libfontconfig.so
[task 2018-07-27T05:35:55.821Z] 05:35:55     INFO - GECKO(2718) |       1         29 libglib-2.0.so
[task 2018-07-27T05:35:55.822Z] 05:35:55     INFO - GECKO(2718) | -----------------------------------------------------
[task 2018-07-27T05:35:55.855Z] 05:35:55     INFO - GECKO(2718) | -----------------------------------------------------
[task 2018-07-27T05:35:55.855Z] 05:35:55     INFO - GECKO(2718) | Suppressions used:
[task 2018-07-27T05:35:55.855Z] 05:35:55     INFO - GECKO(2718) |   count      bytes template
[task 2018-07-27T05:35:55.860Z] 05:35:55     INFO - GECKO(2718) |     636      20288 nsComponentManagerImpl
[task 2018-07-27T05:35:55.860Z] 05:35:55     INFO - GECKO(2718) |       4        832 mozJSComponentLoader::LoadModule
[task 2018-07-27T05:35:55.860Z] 05:35:55     INFO - GECKO(2718) |     611      17713 libfontconfig.so
[task 2018-07-27T05:35:55.860Z] 05:35:55     INFO - GECKO(2718) |       1         29 libglib-2.0.so
[task 2018-07-27T05:35:55.860Z] 05:35:55     INFO - GECKO(2718) | -----------------------------------------------------
[task 2018-07-27T05:35:57.618Z] 05:35:57     INFO - GECKO(2718) | =================================================================
[task 2018-07-27T05:35:57.625Z] 05:35:57    ERROR - GECKO(2718) | ==2718==ERROR: LeakSanitizer: detected memory leaks
[task 2018-07-27T05:35:57.628Z] 05:35:57     INFO - GECKO(2718) | Indirect leak of 2048 byte(s) in 1 object(s) allocated from:

Comment 38

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c767b1b618fbdc8bc894719f5ed7ecdcc9fc5165
Bug 1476405: Part 1 - Allow enumerating non-native nsThread threads. r=erahm

https://hg.mozilla.org/integration/mozilla-inbound/rev/236b366fdf3731ef95e0ba75b8f24f03181343ee
Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads. r=erahm,jld

https://hg.mozilla.org/integration/mozilla-inbound/rev/0b0c243a1827e193d045d6b3566c87ca87035c48
Bug 1476405: Part 2b - Use default thread size from nsIThreadManager in Linux PlatformThreads. r=jld

https://hg.mozilla.org/integration/mozilla-inbound/rev/4831cbfd03ded9ea6dcc8d6f0797f5f80fb717c7
Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads. r=erahm,tcampbell

https://hg.mozilla.org/integration/mozilla-inbound/rev/aeebad4f2dc31901f5b63263169229455e827ac2
Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler. r=erahm,mstange

https://hg.mozilla.org/integration/mozilla-inbound/rev/771288dbf8529d45786b42a21dc66b180bb674ca
Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor. r=erahm

https://hg.mozilla.org/integration/mozilla-inbound/rev/e0a021b27d2c66d46ba973d66d1360678411da26
Bug 1476405: Part 6 - Register AudioIPC threads with the profiler. r=kinetik

https://hg.mozilla.org/integration/mozilla-inbound/rev/ad1674e9152da31151ab9f9f099f83ca4ff2d832
Bug 1476405: Follow-up: Handle nsThread cleanup for threads that never shutdown. r=me

Comment 39

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/c767b1b618fb
https://hg.mozilla.org/mozilla-central/rev/236b366fdf37
https://hg.mozilla.org/mozilla-central/rev/0b0c243a1827
https://hg.mozilla.org/mozilla-central/rev/4831cbfd03de
https://hg.mozilla.org/mozilla-central/rev/aeebad4f2dc3
https://hg.mozilla.org/mozilla-central/rev/771288dbf852
https://hg.mozilla.org/mozilla-central/rev/e0a021b27d2c
https://hg.mozilla.org/mozilla-central/rev/ad1674e9152d

Comment 40

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/77b07565d021
Backed out 8 changesets for causing frequent failures in bug 1479022. a=backout

Comment 41

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f73745f402dfe9185f0c5c69d4f58c1a355678df
Bug 1476405: Part 1 - Allow enumerating non-native nsThread threads. r=erahm

https://hg.mozilla.org/integration/mozilla-inbound/rev/33213060b07a4c2586ca42efde8d2c3a12995a8a
Bug 1476405: Part 2a - Create nsThread wrappers/set names for chromium threads. r=erahm,jld

https://hg.mozilla.org/integration/mozilla-inbound/rev/995910a452a2160283d8f60e38c4c5700b3c1bf9
Bug 1476405: Part 2b - Use default thread size from nsIThreadManager in Linux PlatformThreads. r=jld

https://hg.mozilla.org/integration/mozilla-inbound/rev/8db85769e159e32d4bee06ecb44e3c2e40d15303
Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads. r=erahm,tcampbell

https://hg.mozilla.org/integration/mozilla-inbound/rev/27154b64d897dd5dbe192d2b7f4f5657dd586d74
Bug 1476405: Part 4 - Create nsThread wrappers whenever a thread is registered with the profiler. r=erahm,mstange

https://hg.mozilla.org/integration/mozilla-inbound/rev/748ccf358e9664d958bf355e1993a474ed0c29a3
Bug 1476405: Part 5 - Create nsThread wrapper and use reasonable stack size for BackgroundHangMonitor. r=erahm

https://hg.mozilla.org/integration/mozilla-inbound/rev/d0ef079fa85ebee5a35facda68b630c574f44462
Bug 1476405: Part 6 - Register AudioIPC threads with the profiler. r=kinetik

https://hg.mozilla.org/integration/mozilla-inbound/rev/c31ed05b4863f016b942a387d9767dcf14d8cd75
Bug 1476405: Follow-up: Handle nsThread cleanup for threads that never shutdown. r=me

Comment 42

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/f73745f402df
https://hg.mozilla.org/mozilla-central/rev/33213060b07a
https://hg.mozilla.org/mozilla-central/rev/995910a452a2
https://hg.mozilla.org/mozilla-central/rev/8db85769e159
https://hg.mozilla.org/mozilla-central/rev/27154b64d897
https://hg.mozilla.org/mozilla-central/rev/748ccf358e96
https://hg.mozilla.org/mozilla-central/rev/d0ef079fa85e
https://hg.mozilla.org/mozilla-central/rev/c31ed05b4863

Comment 43

[Kris Maglione [:kmag]]

Note for performance sheriffs: This is part 3 in a series of Bugs which Increase Reported Content Explicit Memory But do not Increase Actual Memory Usage.

Comment 44

[Ionuț Goldan [:igoldan]]

(In reply to Kris Maglione [:kmag] from comment #43)
> Note for performance sheriffs: This is part 3 in a series of Bugs which
> Increase Reported Content Explicit Memory But do not Increase Actual Memory
> Usage.

Thanks for the heads up!

Comment 45

[Ted Campbell [:tcampbell]]

Comment on attachment 8995261 [details]
Bug 1476405: Part 3 - Use reasonable stack sizes and create wrappers for JS threads. r?erahm,tcampbell

Ted Campbell [:tcampbell] has been removed from the revision.