Bug 290901 - browser crashes, plugins stay running
Summary: browser crashes, plugins stay running
Status: CLOSED DUPLICATE of bug 298481
Alias: None
Product: Fedora
Classification: Fedora
Component: nspluginwrapper   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-14 14:45 UTC by Bill Nottingham
Modified: 2014-03-17 03:08 UTC (History)
2 users (show)

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


Attachments (Terms of Use)

Description Bill Nottingham 2007-09-14 14:45:57 UTC
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 18:41:37 UTC
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 13:56:45 UTC
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 16:21:21 UTC
I've still seen crashes here. 

Comment 4 Martin Stransky 2007-10-04 08:19:55 UTC
(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 13:09:17 UTC
No, it seems better at least in that regard. Still crashes with some frequency,
though.

Comment 6 Martin Stransky 2007-10-04 15:38:34 UTC

*** 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.