765158 - Firefox thread behavior since 2012-06-13-03-05-35

Status: RESOLVED FIXED

Description

[omeringen]

Nightly 012-06-12-03-05-27 (fine) :
http://img135.imageshack.us/img135/5378/fx0120612030527.png

Nightly 012-06-14-07-59-12 (buggy) :
http://img59.imageshack.us/img59/7572/fx0120614075912.png

This behavior exists since 2012-06-13-03-05-35 build (2012-06-12-03-05-27 is fine). 

1-) Thread name is different. I checked it via "top" on terminal as you can see.
2-) "top" command on terminal shows it fine but it's somehow reporting to KDE's system monitor wrong. See memory usage(shows 2.12 GB, i have 2 GB ram) is wrong but if i look at details(right click -> detailed mem information) it's right. Except that, CPU state is becoming "stopped/suspended" when firefox use %0 CPU.

What do you think ? Second issue might be related to KDE's system monitor but it was fine until 2012-06-13-03-05-35 build.

Regards. . .

Comment 1

[Tim Taubert [:ttaubert]]

I experience the same and Firefox shows up as "Main Thread" or "RunProcess" in the process list.

Comment 2

[John Tapsell]

Hi.  I'm the ksysguard maintainer.

It would be great for the firefox guys to fix the name of the process.

But I also need to fix the memory problem, and will have a look.

Comment 3

[John Tapsell]

I run the nightly build of firefox, and the process name appeared as "RunProcess".  I could not reproduce the Memory problem though.

When you see the memory problem again, could you please do:

cat /proc/$(pidof firefox)/statm

And paste the output?  (Please also check that "pidof firefox" also returns the same PID that System Activity is using)

Comment 4

[omeringen]

[omer@arch ~]$ pidof firefox
1202
[omer@arch ~]$ cat /proc/$(pidof firefox)/statm
154494 43815 7586 23 0 84796 0

Screenshot :
http://img29.imageshack.us/img29/5089/pidfx.png

Comment 5

[Tim Taubert [:ttaubert]]

This issue is caused by bug 720778.

Comment 6

[John Tapsell]

Can you plese do:

cat /proc/$(pidof firefox)/status

As well?  Thanks

Comment 7

[omeringen]

http://pastie.org/4091819

Comment 8

[Honza Bambas (:mayhemer)]

We probably just need to avoid call of PR_SetCurrentThreadName("Main Thread") on the main thread and then fix the visual event tracer to specially handle main thread's name.

I'll do this on Monday, however anyone feel free to make a patch for this, but please drop a note you do so.  Thanks.

Comment 9

[John Tapsell]

The ksysguard problem should be fixed:

http://commits.kde.org/kde-workspace/169899ce558f54ad1f37e84c18817b05e90c2ba8

Comment 10

[Honza Bambas (:mayhemer)]

Created attachment 634497 [details] [diff] [review]
v1

- removed naming of the main thread
- visual event tracer explicitly uses Main Thread as name of the main thread
- added support for nameless threads in even tracer

Comment 11

[Benjamin Smedberg]

Comment on attachment 634497 [details] [diff] [review]
v1

I really don't think you need gMainThread here. Just use NS_IsMainThread which is TLS-optimized.

Comment 12

[Tony Mechelynck [:tonymec]. (NEEDINFO me if you want my attention)]

(In reply to Tim Taubert [:ttaubert] from comment #1)
> I experience the same and Firefox shows up as "Main Thread" or "RunProcess"
> in the process list.

So do I in SeaMonkey:
Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0 SeaMonkey/2.13a1 ID:20120629003020 CSet: b6b7503a7ed3
http://hg.mozilla.org/mozilla-central/rev/081d8578beb1

and have been for a few days.

$ echo $(pidof seamonkey)
  is the same as the PID of what ps lists as RunProcess
# cat /proc/$(pidof seamonkey)/statm
529543 309442 5858 34 0 406449 0
# cat /proc/$(pidof seamonkey)/status
Name:   RunProcess
State:  R (running)
Tgid:   1741
Pid:    1741
PPid:   1739
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 512
Groups: 0 1000 
VmPeak:  2226636 kB
VmSize:  2108700 kB
VmLck:         0 kB
VmHWM:   1436444 kB
VmRSS:   1205900 kB
VmData:  1616160 kB
VmStk:       164 kB
VmExe:       136 kB
VmLib:     73148 kB
VmPTE:      4164 kB
VmSwap:     2380 kB
Threads:        24
SigQ:   1/24931
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001006
SigCgt: 00000001800144e9
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed:   3
Cpus_allowed_list:      0-1
Mems_allowed:   00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        6808694
nonvoluntary_ctxt_switches:     7571001

...just in case they can be of use to anyone.

Comment 13

[Honza Bambas (:mayhemer)]

Created attachment 638362 [details] [diff] [review]
v2

no gMainThread

Comment 14

[Honza Bambas (:mayhemer)]

Comment on attachment 638362 [details] [diff] [review]
v2

https://hg.mozilla.org/integration/mozilla-inbound/rev/7f6e22f10b99

Comment 15

[Ryan VanderMeulen [:RyanVM]]

http://mozillamemes.tumblr.com/post/21637966463/yes-i-have-a-condition-that-forces-me-to-insert

One of the patches was causing xpcshell failures. Since I didn't see Try results in any of the bugs, I had to backout the entire push.
https://hg.mozilla.org/integration/mozilla-inbound/rev/981ac887f6e2
https://hg.mozilla.org/integration/mozilla-inbound/rev/925562fd7d68

An example:
https://tbpl.mozilla.org/php/getParsedLog.php?id=13404043&tree=Mozilla-Inbound

TEST-INFO | /home/cltbld/talos-slave/test/build/xpcshell/tests/netwerk/test/unit/test_cacheForOfflineUse_no-store.js | running test ...
TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/test/build/xpcshell/tests/netwerk/test/unit/test_cacheForOfflineUse_no-store.js | test failed (with xpcshell return code: 0), see following log:
>>>>>>>

TEST-INFO | (xpcshell/head.js) | test 1 pending

TEST-INFO | (xpcshell/head.js) | test 2 pending

TEST-INFO | (xpcshell/head.js) | test 2 finished

TEST-INFO | (xpcshell/head.js) | running event loop

TEST-INFO | (xpcshell/head.js) | test 2 pending
TEST-INFO | /home/cltbld/talos-slave/test/build/xpcshell/tests/netwerk/test/unit/test_cacheForOfflineUse_no-store.js | Starting test_normal

TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/test/build/xpcshell/head.js | [Exception... "Cannot modify properties of a WrappedNative"  nsresult: "0x80570034 (NS_ERROR_XPC_CANT_MODIFY_PROP_ON_WN)"  location: "JS frame :: /home/cltbld/talos-slave/test/build/xpcshell/tests/netwerk/test/unit/test_cacheForOfflineUse_no-store.js :: make_channel_for_offline_use :: line 21"  data: no] - See following stack:
JS frame :: /home/cltbld/talos-slave/test/build/xpcshell/head.js :: do_throw :: line 451
JS frame :: /home/cltbld/talos-slave/test/build/xpcshell/head.js :: _run_next_test :: line 899
JS frame :: /home/cltbld/talos-slave/test/build/xpcshell/head.js :: <TOP_LEVEL> :: line 418

TEST-INFO | (xpcshell/head.js) | exiting test

TEST-INFO | (xpcshell/head.js) | test 2 finished
<<<<<<<

Comment 16

[Honza Bambas (:mayhemer)]

Comment on attachment 638362 [details] [diff] [review]
v2

https://hg.mozilla.org/integration/mozilla-inbound/rev/c62c64506ad7

Comment 17

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/c62c64506ad7

Comment 18

[denisdoria]

Is this commit also included in Thunderbird? I mean is this part of some shared library and I can consider it fixed, or should I open a ticket for Thunderbird?

Comment 19

[Honza Bambas (:mayhemer)]

(In reply to denisdoria from comment #18)
> Is this commit also included in Thunderbird? I mean is this part of some
> shared library and I can consider it fixed, or should I open a ticket for
> Thunderbird?

This is a platform change that is included in Thunderbird too.

Comment 20

[omeringen]

Thanks for the fix it looks fine but i've just realized that thread name becomed "Runprocess" somehow. Restarted Firefox, it's fine now. I'm gonna try to find a way to repoduce it.

Comment 21

[Tony Mechelynck [:tonymec]. (NEEDINFO me if you want my attention)]

(In reply to omeringen from comment #20)
> Thanks for the fix it looks fine but i've just realized that thread name
> becomed "Runprocess" somehow. Restarted Firefox, it's fine now. I'm gonna
> try to find a way to repoduce it.

Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0 SeaMonkey/2.13a1 ID:20120715003006 CSet: a52505700b63

Here too, I see the SeaMonkey executable process change name from seamonkey-bin to (ultimately) RunProcess, as in my earlier comment #12 and as Firefox did for ttaubert in comment #1. I just did the following while the above build (the one I use to type this comment, almost 3 days later than comment #17) was running:

linux:~ # echo $(pidof seamonkey)
14173
linux:~ # ps -l 14173
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY        TIME CMD
4 S     0 14173 14171 27  80   0 - 481601 -     ?         95:57 seamonkey -P default
linux:~ # ps -l --pid 14173
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
4 S     0 14173 14171 27  80   0 - 481729 -     ?        01:35:59 RunProcess
linux:~ # ps -lC seamonkey,RunProcess
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
4 R     0 14173 14171 27  80   0 - 521555 -     ?        01:36:39 RunProcess

Notice the difference depending on calling with one PID (and no selection switch) or with a (singleton) list of PIDs (--pid). When selecting by program name (-C) on both "seamonkey" and "RunProcess", only the latter appears. When selecting on only "-C seamonkey" (not shown) ps outputs only column headings, no processes.

The PPID points to the script which I use to start SeaMonkey with the correct profile and logfile, as follows:

linux:~ # ps -l 14171
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY        TIME CMD
1 S     0 14171     1  0  80   0 -  3270 wait   ?          0:00 /bin/bash /usr/local/bin/start-sm-all
linux:~ # cat /usr/local/bin/start-sm-all
#!/bin/bash
(date && seamonkey -P default) >> ~/seamonkey.log 2>&1 &

Comment 22

[Tim Taubert [:ttaubert]]

Confirming for Firefox as well. Process has been started a while ago and is called "RunProcess".

Comment 23

[Tony Mechelynck [:tonymec]. (NEEDINFO me if you want my attention)]

P.S. "RunProcess" is also the process name shown me for this process by the "top" utility.

Comment 24

[Honza Bambas (:mayhemer)]

Please continue commenting on bug 774243 instead.

This bug has been fixed and symptoms are now different.