Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

xulrunner incredible ammount of calls to getrlimit while running flash

125 views
Skip to first unread message

Estanislao Gonzalez

unread,
Sep 20, 2012, 9:14:49 AM9/20/12
to dev-pl...@lists.mozilla.org
Hi,

This is probably nothing... but I was testing something else and I wondered why there are so many calls to getrlimit about the size of the stack...

These are the "top 10" calls from one second dump of strace for the xulrunner process (first field is the count):

$ (strace -p 10762 2>&1 & sleep 1 && pkill strace) | awk '{a[$0]+=1} END {for (k in a) {print a[k],k}}' | sort -k 1 -rn | head

58498 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
53 read(13, 0xb4d65058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
26 poll([{fd=4, events=POLLIN}, {fd=13, events=POLLIN}, {fd=6, events=POLLIN}], 3, 0) = 0 (Timeout)
16 poll([{fd=4, events=POLLIN}, {fd=13, events=POLLIN}], 2, 0) = 0 (Timeout)
12 semop(131073, {{0, -1, SEM_UNDO}}, 1) = 0
12 semop(131073, {{0, 1, SEM_UNDO}}, 1) = 0
6 poll([{fd=4, events=POLLIN}, {fd=13, events=POLLIN}, {fd=6, events=POLLIN}], 3, 9) = 0 (Timeout)
5 write(7, "!", 1) = 1
5 read(6, "!", 1) = 1
5 poll([{fd=4, events=POLLIN}, {fd=13, events=POLLIN}, {fd=6, events=POLLIN}], 3, 0) = 1 ([{fd=6, revents=POLLIN}])

so there are almost 60.000 calls per second (min:53.000 max:64.000) to RLIMIT_STACK ...

I must be missing something...

I could trim it down to this pages:
http://www.merriam-webster.com/dictionary/xul - 10.058 calls per second (pretty stable +/- 2) video there was off

When starting the video it spiked to 55.000 and remained there while loading (even after the video was paused). The plugin crashed soon afterwards.
A second try showed the same numbers. When the video finished loading it remained at ~60.000 and after it stopped it remained the same.
This only stops if the tab is closed.

Some data:

$ iceweasel -v
Mozilla Iceweasel 10.0.6

$ ps ux | grep xulrunner
user 14065 5.7 0.5 228076 43484 ? SLl 14:56 0:29 /usr/lib/xulrunner-10.0/plugin-container /usr/lib/flashplayer-mozilla/libflashplayer.so -greomni /usr/lib/xulrunner-10.0/omni.ja 13625 plugin

$ uname -a
Linux tux104 2.6.32-5-686-bigmem #1 SMP Sun May 6 04:39:05 UTC 2012 i686 GNU/Linux

$ lsb_release -d
Description: Debian GNU/Linux 6.0.5 (squeeze)

flash player: 11.2.202.236

probably is nothing but it does look awkward to me...

Cheers,
Estani

--
Estanislao Gonzalez
Institute of Meteorology
Freie Universität Berlin
Climate System Modeling Working Group
Carl-Heinrich-Becker Weg 6-10, Room 079 AB/1
D-12165 Berlin

Phone: +49 30 838-71116
Mail: estanisla...@met.fu-berlin.de

Benjamin Smedberg

unread,
Sep 20, 2012, 9:29:56 AM9/20/12
to Estanislao Gonzalez, dev-pl...@lists.mozilla.org
On 9/20/2012 9:14 AM, Estanislao Gonzalez wrote:
> Hi,
>
> This is probably nothing... but I was testing something else and I wondered why there are so many calls to getrlimit about the size of the stack...
>
> These are the "top 10" calls from one second dump of strace for the xulrunner process (first field is the count):
>
> $ (strace -p 10762 2>&1 & sleep 1 && pkill strace) | awk '{a[$0]+=1} END {for (k in a) {print a[k],k}}' | sort -k 1 -rn | head
>
> 58498 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
> 53 read(13, 0xb4d65058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
> 26 poll([{fd=4, events=POLLIN}, {fd=13, events=POLLIN}, {fd=6, events=POLLIN}], 3, 0) = 0 (Timeout)
> 16 poll([{fd=4, events=POLLIN}, {fd=13, events=POLLIN}], 2, 0) = 0 (Timeout)
> 12 semop(131073, {{0, -1, SEM_UNDO}}, 1) = 0
> 12 semop(131073, {{0, 1, SEM_UNDO}}, 1) = 0
> 6 poll([{fd=4, events=POLLIN}, {fd=13, events=POLLIN}, {fd=6, events=POLLIN}], 3, 9) = 0 (Timeout)
> 5 write(7, "!", 1) = 1
> 5 read(6, "!", 1) = 1
> 5 poll([{fd=4, events=POLLIN}, {fd=13, events=POLLIN}, {fd=6, events=POLLIN}], 3, 0) = 1 ([{fd=6, revents=POLLIN}])
>
> so there are almost 60.000 calls per second (min:53.000 max:64.000) to RLIMIT_STACK ...
This is while running Firefox? Or some other XULRunner-based app?

The ps list below shows seems to indicate that you're seeing the
plugin-container process for Flash player. If this is correct, and
you're looking at a Flash-based video, it is *probably* the Flash player
code which is making these getrlimit calls. It would be good to get
some basic stack traces from the calls to verify my hunch, of course. If
they walk directly into libflashplayer.so then this is something you
should report to Adobe.

Does anyone know how expensive getrlimit is?

--BDS

Estanislao Gonzalez

unread,
Sep 20, 2012, 9:56:19 AM9/20/12
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
I did asume this was caused by the flash player library (to some extent). It is while running iceweasel (firefox debian version).

And you were right:

#0 0xb65dbd7a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1 0xb320659f in ?? () from /usr/lib/flashplayer-mozilla/libflashplayer.so
#2 0xb2dce2e5 in ?? () from /usr/lib/flashplayer-mozilla/libflashplayer.so
#3 0xb320685c in ?? () from /usr/lib/flashplayer-mozilla/libflashplayer.so
#4 0xb3206f06 in ?? () from /usr/lib/flashplayer-mozilla/libflashplayer.so
#5 0xb65d77b0 in start_thread () from /lib/libpthread.so.0
#6 0xb653b0be in clone () from /lib/libc.so.6

So, wrong list :-)

getrlimit is not expensive at all... but that doesn't mean you can call it 60.000 per second without incurring in any penalty...

Thanks,

Estanislao Gonzalez

unread,
Sep 20, 2012, 10:02:56 AM9/20/12
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
I might have answered too fast...
#0 0xb653b8ec in epoll_wait () from /lib/libc.so.6
#1 0xb5b5ec97 in ?? () from /usr/lib/libevent-1.4.so.2
#2 0xb5b51c5a in event_base_loop () from /usr/lib/libevent-1.4.so.2
#3 0xb7330e80 in ?? () from /usr/lib/xulrunner-10.0/libxul.so
#4 0xb7702ea2 in moz_free () from /usr/lib/xulrunner-10.0/libmozalloc.so
#5 0xb771a580 in ?? () from /lib/ld-linux.so.2
#6 0xb7323c3b in ?? () from /usr/lib/xulrunner-10.0/libxul.so
#7 0xb653b0be in clone () from /lib/libc.so.6

How can I check how many calls come from which library to see who's the relevant culprit?
(a step by step shows (now) one from each...)

Thanks,
Estani

PS: feel free to dismiss this subject by not answering.

Benjamin Smedberg

unread,
Sep 20, 2012, 10:33:15 AM9/20/12
to Estanislao Gonzalez, dev-pl...@lists.mozilla.org
On 9/20/2012 10:02 AM, Estanislao Gonzalez wrote:
> I might have answered too fast...
> #0 0xb653b8ec in epoll_wait () from /lib/libc.so.6
> #1 0xb5b5ec97 in ?? () from /usr/lib/libevent-1.4.so.2
> #2 0xb5b51c5a in event_base_loop () from /usr/lib/libevent-1.4.so.2
> #3 0xb7330e80 in ?? () from /usr/lib/xulrunner-10.0/libxul.so
> #4 0xb7702ea2 in moz_free () from /usr/lib/xulrunner-10.0/libmozalloc.so
> #5 0xb771a580 in ?? () from /lib/ld-linux.so.2
> #6 0xb7323c3b in ?? () from /usr/lib/xulrunner-10.0/libxul.so
> #7 0xb653b0be in clone () from /lib/libc.so.6
>
> How can I check how many calls come from which library to see who's the relevant culprit?
> (a step by step shows (now) one from each...)
You should expect plugin-container to call epoll_wait, but not at
60k/sec rates ;-) I would focus on only the getrlimit calls, and use
something like strace+ (1) to classify them by stack.

--BDS

1. http://code.google.com/p/strace-plus/

dpi...@gmail.com

unread,
Jan 21, 2013, 11:14:41 AM1/21/13
to Benjamin Smedberg, dev-pl...@lists.mozilla.org
I also get this, but only with flash 11.2, but not with 11.5.
Any idea how to solve it?

dpi...@gmail.com

unread,
Jan 21, 2013, 11:14:41 AM1/21/13
to mozilla.de...@googlegroups.com, Benjamin Smedberg, dev-pl...@lists.mozilla.org

On Thursday, September 20, 2012 3:59:59 PM UTC+2, Estanislao Gonzalez wrote:
0 new messages