Bug 290901 - browser crashes, plugins stay running
browser crashes, plugins stay running
Status: CLOSED DUPLICATE of bug 298481
Product: Fedora
Classification: Fedora
Component: nspluginwrapper (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-14 10:45 EDT by Bill Nottingham
Modified: 2014-03-16 23:08 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-04 11:38:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2007-09-14 10:45:57 EDT
Description of problem:

In a neat turnaround from prior behavior, sometimes the browser crashes while
npviewer.bin (flash) keeps running.

Version-Release number of selected component (if applicable):

nspluginwrapper-0.9.91.5-2.fc8
firefox-2.0.0.6-8.fc8

How reproducible:

Occasionally. Sometimes everything crashes.
Comment 1 Bill Nottingham 2007-09-18 14:41:37 EDT
Here's a trace.

[Switching to Thread 46912597138704 (LWP 5973)]
rpc_method_get_args (connection=0x27c7210) at ../src/rpc.c:756
756     ../src/rpc.c: No such file or directory.
        in ../src/rpc.c
Current language:  auto; currently c
#0  rpc_method_get_args (connection=0x27c7210) at ../src/rpc.c:756
#1  0x00002aaac95f6178 in npclass_handle_Invalidate (connection=0x27c7210) at
../src/npruntime.c:68
#2  0x00002aaac95f30c3 in _rpc_dispatch (connection=0x27c7210,
message=0x7ffff209b3c0)
    at ../src/rpc.c:1366
#3  0x00002aaac95f4db4 in rpc_method_wait_for_reply (connection=0x27c7210) at
../src/rpc.c:1640
#4  0x00002aaac95f6130 in npclass_invoke_Invalidate (npobj=<value optimized out>)
    at ../src/npruntime.c:96
#5  0x00002aaac95f61d3 in npclass_handle_Invalidate (connection=<value optimized
out>)
    at ../src/npruntime.c:77
#6  0x00002aaac95f30c3 in _rpc_dispatch (connection=0x27c7210,
message=0x7ffff209d6d0)
    at ../src/rpc.c:1366
#7  0x00002aaac95f4db4 in rpc_method_wait_for_reply (connection=0x27c7210) at
../src/rpc.c:1640
#8  0x00002aaac95f6130 in npclass_invoke_Invalidate (npobj=<value optimized out>)
    at ../src/npruntime.c:96
#9  0x00002aaac95f61d3 in npclass_handle_Invalidate (connection=<value optimized
out>)
    at ../src/npruntime.c:77
#10 0x00002aaac95f30c3 in _rpc_dispatch (connection=0x27c7210,
message=0x7ffff209f9e0)
    at ../src/rpc.c:1366
#11 0x00002aaac95f4db4 in rpc_method_wait_for_reply (connection=0x27c7210) at
../src/rpc.c:1640
#12 0x00002aaac95f6130 in npclass_invoke_Invalidate (npobj=<value optimized out>)
    at ../src/npruntime.c:96
#13 0x00002aaac95f61d3 in npclass_handle_Invalidate (connection=<value optimized
out>)
    at ../src/npruntime.c:77
#14 0x00002aaac95f30c3 in _rpc_dispatch (connection=0x27c7210,
message=0x7ffff20a1cf0)
    at ../src/rpc.c:1366
#15 0x00002aaac95f4db4 in rpc_method_wait_for_reply (connection=0x27c7210) at
../src/rpc.c:1640
#16 0x00002aaac95f6130 in npclass_invoke_Invalidate (npobj=<value optimized out>)
    at ../src/npruntime.c:96
#17 0x00002aaac95f61d3 in npclass_handle_Invalidate (connection=<value optimized
out>)
    at ../src/npruntime.c:77
#18 0x00002aaac95f30c3 in _rpc_dispatch (connection=0x27c7210,
message=0x7ffff20a4000)
    at ../src/rpc.c:1366
#19 0x00002aaac95f4db4 in rpc_method_wait_for_reply (connection=0x27c7210) at
../src/rpc.c:1640
#20 0x00002aaac95f6130 in npclass_invoke_Invalidate (npobj=<value optimized out>)
    at ../src/npruntime.c:96
...

It appears that nspluginwrapper is recursing somewhere in it's rpc code, and
eventually blows its stack. (the same functions continue for about 2000 frames
before I got tired of listing the backtrace.)
Comment 2 Martin Stransky 2007-10-01 09:56:45 EDT
Should be fixed in nspluginwrapper-0.9.91.5-4.fc8. It uses gtk_main_quit(); so
it may not work if there's some hard deadlock...
Comment 3 Bill Nottingham 2007-10-03 12:21:21 EDT
I've still seen crashes here. 
Comment 4 Martin Stransky 2007-10-04 04:19:55 EDT
(In reply to comment #3)
> I've still seen crashes here. 

Is the plugin running after that or not?
Comment 5 Bill Nottingham 2007-10-04 09:09:17 EDT
No, it seems better at least in that regard. Still crashes with some frequency,
though.
Comment 6 Martin Stransky 2007-10-04 11:38:34 EDT

*** This bug has been marked as a duplicate of 298481 ***

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