1537951 - Too many unknown threads in the parent process of FXR

Status: RESOLVED FIXED

(GeckoView :: General, defect, P1)

Description

[(no longer active)]

I'm seeing too many unknown threads in the parent process of FXR, for example 183 threads in one run, 168 threads in another run...

In one example, listing the threads with top -H, I saw 21 threads named "Gecko", 23 named "zilla.vrbrowser", 10 named "RenderThread", etc. It is unclear where these threads are coming from.

When running the cube-aframe test, I see that some of these are busy running code in the parent process, for example one of the "zilla.vrbrowser" threads and one of the "Gecko" threads (as well as "Thread-31"). Unclear what code they were running, I haven't been able to find a profiling tool that can shed some light into this.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Perhaps when we spawn an unnamed thread we can (optionally) name it with the code (file/line) that called NewThread, or that caused a non-nsThread to be upgraded to an nsThread (such as by calling Dispatch() with SYNC). And/or throw NS_Assertions on unnamed threads to record the stacks that created them - and/or LOG them.

The real issue here is the number of unnamed threads specific to FXR, I think though. Perhaps some of them (many of them?) aren't nsThreads at all (pthreads or whatever). Breakpoints or logging on pthread_create and the like would help. if they are.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

I would suggest inspecting the number (and names) of threads at a few specific points:

1. In Activity.onCreate, before any other action is taken. This would show us how many threads are inherited from the zygote itself.

2. If possible, after initializing any Oculus-related stuff, but before starting GeckoRuntime

3. After Gecko is running, which I guess we've already done.

Comment 3

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

I like the idea of making it harder to create unnamed threads, but that should probably happen in a separate bug that this one depends on.

Comment 4

[Markus Stange [:mstange]]

Randall, are you the right person to look into this? Following snorp's suggestions from comment 2 sounds like a good start. Alternatively, is it possible to use the debugger to set a breakpoint on a thread creation function?

Comment 5

[Randall Barker [:rbarker]]

I can at least start by trying to name the FxR specific threads again. Last time I tried, I couldn't get it to work.

Comment 6

[Randall Barker [:rbarker]]

:mstange, I did a little digging and found that PR_SetCurrentThreadName() is broken on android. After fixing PR_SetCurrentThreadName() there are only two Gecko threads left, one is the actual gecko main thread and the other is a breakpad thread. I will investigate where the other zilla.vrbrowser threads (about 90) are coming from next but since all the stack from those threads do not have symbols, I'm starting to suspect a third party library. I ran the NoAPI version to eliminate third party VR APIs. I plan to investigate the voice search and google VR Audio libraries next.

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

To help know the impact of these threads, it would be good to know:

• How large the stack size of these threads are.
• How much of these thread stacks are committed.

Are we running a 32bit or 64bit build here? That determines how much the reserved space hurts us.

Comment 8

[Randall Barker [:rbarker]]

After further investigation, I have found the 90 zilla.vrbrowser threads are created by the third party audio library GvrAudioEngine. See: https://developers.google.com/vr/reference/android/com/google/vr/sdk/audio/GvrAudioEngine

I will open an issue for FxR but I think this bug may now be closed.

Comment 9

[Randall Barker [:rbarker]]

https://github.com/MozillaReality/FirefoxReality/issues/1057

Comment 10

[Randall Barker [:rbarker]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1541285

Comment 11

[Randall Barker [:rbarker]]

fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1541282