Bug 469505 - npviewer uses 100% cpu and hangs
Summary: npviewer uses 100% cpu and hangs
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nspluginwrapper
Version: 9
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL: http://www.nytimes.com
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-11-01 17:03 UTC by Jonathan Baron
Modified: 2018-04-11 16:41 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-13 23:28:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jonathan Baron 2008-11-01 17:03:32 UTC
Description of problem: npviewer hangs and uses lots of capacity at various times, but most reliably when using the back button in Firefox after viewing the New York Times web page


Version-Release number of selected component (if applicable):
nspluginwrapper-1.1.2-2.fc9.x86_64
nspluginwrapper-1.1.2-2.fc9.i386


How reproducible:
about 75% of the time

Steps to Reproduce:
1. go to NY times web site with Firefox
2. browse a little
3. use the back button to go back to where you came from
  
Actual results:
takes about 30 sec, first CPU indicates 100% capacity during this time taken up by npviewer


Expected results:
back out immediately

Additional info:
This has been discussed a lot in various newsgroups and lists, google for "npviewer cpu".  But I don't think it has actually been reported as a bug.  It isn't clear that everyone has the same problem.  It started for me a couple of weeks ago, perhaps with the new version of nspluginwrapper.  Someone recommended changing security settings, but that didn't help.  Neither did reinstalling plugins with mozilla-plugin-config.  But who knows what else it may depend on!

I'm actually using Minefield (latest build of Firefox), but from what I've read that doesn't matter.

Comment 1 Martin Stransky 2008-11-12 15:50:27 UTC
When this happen, please attach debugger to the npviewer process (gdb --pid=XXX) where XXX is a PID of npviewer process and attach back-trace here... ("bt" gdb command)

Comment 2 Jonathan Baron 2008-11-13 00:04:27 UTC
(In reply to comment #1)
> When this happen, please attach debugger to the npviewer process (gdb
> --pid=XXX) where XXX is a PID of npviewer process and attach back-trace here...
> ("bt" gdb command)

I tried this, but I did not understand the last line, and
man gdb
did not help.  I'm afraid that I need more specific instructions.
I typed bt and got a "no trace" message.
I will be able to do this on 11/13 but then not for the next 4 days.
Sorry.

Comment 3 Jonathan Baron 2008-11-18 15:24:38 UTC
(In reply to comment #1)
> When this happen, please attach debugger to the npviewer process (gdb
> --pid=XXX) where XXX is a PID of npviewer process and attach back-trace here...
> ("bt" gdb command)

I think I got this to work.  I had to go to the NYT website to get a pid for npviewer, which apparently is run only when needed, the pid was 6392. Then I said (not what you suggested):

gdb npviewer 6392

I got a gdb prompt.  Then things hung for a while; I could not scroll the page.  After that, I said

bt

and got the following.  I should say that it is now much harder to replicate this bug.  It used to happen most of the time.  Now it is rare.  It could be the new xorg.  But I suspect it depends on what ads show up in the NYT web page.

#0  0x00110430 in __kernel_vsyscall ()
#1  0x002a9a57 in poll () from /lib/libc.so.6
#2  0x005fd372 in ?? () from /lib/libglib-2.0.so.0
#3  0x005fda02 in g_main_loop_run () from /lib/libglib-2.0.so.0
#4  0x05125d45 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#5  0x08051588 in pthread_cancel ()
#6  0x001ec5d6 in __libc_start_main () from /lib/libc.so.6
#7  0x0804ac71 in pthread_cancel ()

Note, this is not the usual symptom.  The most common symptom is that things hang when I use the back button to get out of the NYT web page.  But I could not replicate that today.

Comment 4 Jonathan Baron 2008-11-18 19:22:02 UTC
(In reply to comment #3)
> (In reply to comment #1)
> Note, this is not the usual symptom.  The most common symptom is that things
> hang when I use the back button to get out of the NYT web page.  But I could
> not replicate that today.

I got the usual symptom and got the identical response from bt.

Comment 5 Matěj Cepl 2009-01-13 15:43:28 UTC
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

First of all, could we get output of the command

	rpm -qa *xulrun* *firefox* *mozilla* *flash* *plugin*

Please also install firefox-debuginfo (debuginfo-install is from
yum-utils package).

	debuginfo-install firefox

Then run firefox with a parameter -g. That will start firefox running inside of gdb debugger. Then use command run and do whatever you did to make firefox crash. When it happens, you should go back to the gdb and run

	(gdb) thread apply all backtrace

This produces usually many screens of the text. Copy all of them into a text editor and attach the file to the bug as an uncompressed attachment.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 6 Martin Stransky 2009-01-13 15:49:07 UTC
The "thread apply all backtrace" should provide more info about the crash. 
Or you may install updated nspluginwrapper package (1.3.0) from rawhide.

Comment 7 Jonathan Baron 2009-01-13 22:58:54 UTC
(In reply to comment #6)
> The "thread apply all backtrace" should provide more info about the crash. 
> Or you may install updated nspluginwrapper package (1.3.0) from rawhide.

Sorry, but I can't do this now.  After several weeks, I gave up.  I removed nspluginwrapper and installed the x86_64 version (beta?) of Adobe Flash, and all is well.  I suppose nspluginwrapper may be useful for something else, but I don't know what it is.  I understand that swfdec may even work now, but I haven't tried it (again).

Comment 8 Matěj Cepl 2009-01-13 23:28:00 UTC
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information.

Closing as INSUFFICIENT_DATA.

Comment 9 hkoba 2009-06-19 00:57:12 UTC
Me too observed this sometime.
It occured randomly after acpi suspend/resume. 

-------------------------
top - 09:08:51 up 2 days, 20:35,  2 users,  load average: 0.15, 0.37, 0.35
Tasks: 220 total,   2 running, 217 sleeping,   0 stopped,   1 zombie
Cpu(s):  5.1%us,  1.2%sy,  0.9%ni, 92.1%id,  0.6%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3473448k total,  3388180k used,    85268k free,   524032k buffers
Swap:  4194296k total,       68k used,  4194228k free,  1441928k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
17029 hkoba     20   0  198m  42m  15m S 33.5  1.3   7:46.15 npviewer.bin       
15844 hkoba     20   0  842m 310m  30m S  3.9  9.1   9:10.09 firefox            
    1 root      20   0  4092  912  648 S  0.0  0.0   0:03.30 init               
    2 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kthreadd           
-------------------------
# Note: CPU usage became worse few seconds later.


Inspecting this by gdb, I saw frequent call of IA__g_source_get_current_time().
--------------------------
(gdb) bt
#0  IA__g_source_get_current_time (source=0x9e98590, timeval=0xffff9138)
    at gmain.c:3292
#1  0x0085299e in g_timeout_dispatch (source=0x9e98590, callback=0x102a960,
    user_data=0xf7341000) at gmain.c:3593
#2  0x00852258 in g_main_dispatch () at gmain.c:2144
#3  IA__g_main_context_dispatch (context=0x9860b40) at gmain.c:2697
#4  0x00855903 in g_main_context_iterate (context=0x9860b40, block=1,
    dispatch=1, self=0x983c900) at gmain.c:2778
#5  0x00855e22 in IA__g_main_loop_run (loop=0x9860088) at gmain.c:2986
#6  0x003ac959 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#7  0x0804f561 in do_main (argv=0xffff93f4, argc=1) at ../src/npw-viewer.c:4501
#8  main (argc=1, argv=0xffff93f4) at ../src/npw-viewer.c:4675
(gdb) 
--------------------------

I do not know enough about glib dispatching mechanism, but I suspect
npviewer might forgot removing this (gettimeofday?) task.


Note You need to log in before you can comment on or make changes to this bug.