Bug 472680 - gnash plugin crashes Firefox when used together with FlashBlock
gnash plugin crashes Firefox when used together with FlashBlock
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnash (Show other bugs)
10
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Kevin Kofler
Fedora Extras Quality Assurance
http://www.ozone.ru
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-23 06:45 EST by Stas Sergeev
Modified: 2009-12-18 01:55 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:55:36 EST
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 Stas Sergeev 2008-11-23 06:45:13 EST
Description of problem:
When I view the pages with flash, firefox
usually crashes, unless I uninstall the
gnash-plugin. This is most reproduceable
with the above URL (www.ozone.ru). If it
doesn't crash the first time, press reload,
and it should.

Version-Release number of selected component (if applicable):
gnash-0.8.4-5.fc9.x86_64
gnash-plugin-0.8.4-5.fc9.x86_64
firefox-3.0.4-1.fc9.x86_64

How reproducible:
90% of attempts.
Using "reload" will make the 100% crash reliability.

Steps to Reproduce:
1. Install gnash-plugin, if not yet
2. Open www.ozone.ru
3. Press "reload" if it doesn't crash the
first time.
  
Actual results:
Firefox crashes

Expected results:
Page complete with the flash animation

Additional info:
This bug was not there in F8, IIRC.
Comment 1 Patrice Dumas 2008-11-23 08:52:05 EST
This may be a duplicate of Bug 469196.
Comment 2 Stas Sergeev 2008-11-23 13:40:59 EST
Bug 469196 said to be unreproduceable on
x86-32. Is it the same here? I don't have
x86-32 around to test...
Comment 3 Patrice Dumas 2008-11-23 19:13:58 EST
I indeed cannot reproduce it on ix86.
Comment 4 Stas Sergeev 2008-12-10 08:54:59 EST
Hmm, I can't reproduce it today either.
This is odd given that neither firefox
nor gnash were recently updated, even
though there were some unrelated updates.
I'll leave the plugin installed for some
time to see if it still crashes or not.
Comment 5 Stas Sergeev 2008-12-11 13:57:57 EST
OK, it is still reproduceable.
Here's the stack trace.
Seems a bit different from Bug 469196.

---
#0  0x00007f0ae5fd5470 in ?? ()
No symbol table info available.
#1  0x00007f0b03e6179b in g_main_dispatch () at gmain.c:2144
No locals.
#2  IA__g_main_context_dispatch (context=0xb19c90) at gmain.c:2697
No locals.
#3  0x00007f0b03e64f6d in g_main_context_iterate (context=0xb19c90, block=0, 
    dispatch=1, self=<value optimized out>) at gmain.c:2778
	max_priority = 2147483647
	timeout = 0
	some_ready = 1
	nfds = 12
	allocated_nfds = <value optimized out>
	fds = (GPollFD *) 0x418aa80
	__PRETTY_FUNCTION__ = "g_main_context_iterate"
#4  0x00007f0b03e6512b in IA__g_main_context_iteration (context=0xb19c90, 
    may_block=0) at gmain.c:2841
	retval = <value optimized out>
#5  0x00007f0b0712d279 in nsBaseAppShell::DoProcessNextNativeEvent (
    this=0x52205b0, mayWait=16) at nsBaseAppShell.cpp:151
	prevVal = nsBaseAppShell::eEventloopNone
	result = 16
#6  0x00007f0b0712d42a in nsBaseAppShell::OnProcessNextEvent (this=0xc6ead0, 
---Type <return> to continue, or q <return> to quit---
    thr=0xb9a680, mayWait=1, recursionDepth=<value optimized out>)
    at nsBaseAppShell.cpp:278
	now = 43263616
	keepGoing = <value optimized out>
	start = 661025087
	limit = 20
	oldBlockedWait = (PRBool *) 0x0
	needEvent = 1
#7  0x00007f0b071f6d77 in nsThread::ProcessNextEvent (this=0xb9a680, 
    mayWait=1, result=0x7fff10ea248c) at nsThread.cpp:497
	notifyGlobalObserver = 1
	obs = {<nsCOMPtr_base> = {mRawPtr = 0xc6ead8}, <No data fields>}
	event = {<nsCOMPtr_base> = {
    mRawPtr = 0x7f0ae8021080}, <No data fields>}
	rv = 2147549183
#8  0x00007f0b071c8aba in NS_ProcessNextEvent_P (thread=0x52205b0, mayWait=1)
    at nsThreadUtils.cpp:227
	val = <value optimized out>
#9  0x00007f0b0712d4e5 in nsBaseAppShell::Run (this=0xc6ead0)
    at nsBaseAppShell.cpp:170
	thread = (class nsIThread *) 0xb9a680
#10 0x00007f0b06fec08d in nsAppStartup::Run (this=0xcbc850)
    at nsAppStartup.cpp:181
---Type <return> to continue, or q <return> to quit---
	rv = <value optimized out>
#11 0x00007f0b069e3bf0 in XRE_main (argc=<value optimized out>, 
    argv=<value optimized out>, aAppData=<value optimized out>)
    at nsAppRunner.cpp:3174
	obsService = {<nsCOMPtr_base> = {mRawPtr = 0xc2be10}, <No data fields>}
	remoteService = {<nsCOMPtr_base> = {
    mRawPtr = 0x16d06d0}, <No data fields>}
	appStartup = {<nsCOMPtr_base> = {mRawPtr = 0xcbc850}, <No data fields>}
	workingDir = {<nsCOMPtr_base> = {mRawPtr = 0xc619f0}, <No data fields>}
	chromeObserver = {<nsCOMPtr_base> = {
    mRawPtr = 0xc29da0}, <No data fields>}
	cmdLine = {<nsCOMPtr_base> = {mRawPtr = 0xc619b0}, <No data fields>}
	noEMRestart = <value optimized out>
	xpcom = {mServiceManager = 0xb96c98}
	desktopStartupIDEnv = <value optimized out>
	updRoot = {<nsCOMPtr_base> = {mRawPtr = 0xaebab0}, <No data fields>}
	persistent = 1
	profLD = {<nsCOMPtr_base> = {mRawPtr = 0xb9ab10}, <No data fields>}
	dirProvider = {<nsIDirectoryServiceProvider2> = {<nsIDirectoryServiceProvider> = {<nsISupports> = {
        _vptr.nsISupports = 0x7f0b078ada10}, <No data fields>}, <No data fields>}, <nsIProfileStartup> = {<nsISupports> = {
      _vptr.nsISupports = 0x7f0b078ada58}, <No data fields>}, 
---Type <return> to continue, or q <return> to quit---
  mAppProvider = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}, 
  mGREDir = {<nsCOMPtr_base> = {mRawPtr = 0xaebb80}, <No data fields>}, 
  mXULAppDir = {<nsCOMPtr_base> = {mRawPtr = 0xaebab0}, <No data fields>}, 
  mProfileDir = {<nsCOMPtr_base> = {mRawPtr = 0xb9aa40}, <No data fields>}, 
  mProfileLocalDir = {<nsCOMPtr_base> = {
      mRawPtr = 0xb9ab10}, <No data fields>}, mProfileNotified = 1 '\001', 
  mExtensionsLoaded = 1 '\001', mAppBundleDirectories = {<nsCOMArray_base> = {
      mArray = {mImpl = 0x0}}, <No data fields>}, 
  mExtensionDirectories = {<nsCOMArray_base> = {mArray = {
        mImpl = 0xbcd5f0}}, <No data fields>}, 
  mThemeDirectories = {<nsCOMArray_base> = {mArray = {
        mImpl = 0xbce280}}, <No data fields>}}
	nativeApp = {<nsCOMPtr_base> = {mRawPtr = 0xb70300}, <No data fields>}
	desktopStartupIDPtr = <value optimized out>
	startOffline = 0
	profileName = {<nsFixedCString> = {<nsCString> = {<nsACString_internal> = {<nsCSubstring_base> = {<No data fields>}, mData = 0xb9af28 "default", 
        mLength = 7, mFlags = 65541}, <No data fields>}, mFixedCapacity = 63, 
    mFixedBuf = 0x7fff10ea2a80 ""}, 
  mStorage = "\000,�\020�\177\000\000\002\000\000\000\000\000\000\000�*�\020�\177\000\000���\000\000\000\000\000�*�\020\r\000\000\000�*�\020�\177\000\0000+�\020�\177\000\000��\036\a\v\177\000"}
	upgraded = 119147810
---Type <return> to continue, or q <return> to quit---
	versionOK = <value optimized out>
	appInitiatedRestart = <value optimized out>
	desktopStartupID = {<nsFixedCString> = {<nsCString> = {<nsACString_internal> = {<nsCSubstring_base> = {<No data fields>}, 
        mData = 0x7fff10ea2ae0 "gnome-panel/firefox/3157-11-lin2_TIME2699480", 
        mLength = 44, mFlags = 65553}, <No data fields>}, mFixedCapacity = 63, 
    mFixedBuf = 0x7fff10ea2ae0 "gnome-panel/firefox/3157-11-lin2_TIME2699480"}, mStorage = "gnome-panel/firefox/3157-11-lin2_TIME2699480\000\177\000\000�\000\000\000\000\000\000\000\000\202\201\000\000���"}
	canRun = 1
	xremotearg = <value optimized out>
	profileLock = {<nsCOMPtr_base> = {
    mRawPtr = 0xb93b50}, <No data fields>}
	profD = {<nsCOMPtr_base> = {mRawPtr = 0xb9aa40}, <No data fields>}
	version = {<nsFixedCString> = {<nsCString> = {<nsACString_internal> = {<nsCSubstring_base> = {<No data fields>}, 
        mData = 0x7fff10ea2a20 "3.0.4_2008111217/2008111217", mLength = 27, 
        mFlags = 65553}, <No data fields>}, mFixedCapacity = 63, 
    mFixedBuf = 0x7fff10ea2a20 "3.0.4_2008111217/2008111217"}, 
  mStorage = "3.0.4_2008111217/2008111217\000\v\177\000\000\000�[\006\v\177\000\000�\000\000\000\000\000\000\000�\000\000\000\000\000\000\000�*�\020�\177\000"}
	needsRestart = 0
	display = (GdkDisplay *) 0xb0f060
---Type <return> to continue, or q <return> to quit---
	osABI = {<nsCString> = {<nsACString_internal> = {<nsCSubstring_base> = {<No data fields>}, mData = 0x7f0b07255057 "Linux_x86_64-gcc3", mLength = 17, 
      mFlags = 1}, <No data fields>}, <No data fields>}
	rv = 0
	ar = <value optimized out>
	gtkModules = <value optimized out>
	override = 0x0
	appData = {<nsXREAppData> = {size = 112, ry = 0xaebab0, 
    vendor = 0xaec590 "Mozilla", name = 0xaec550 "Firefox", 
    version = 0xaec570 "3.0.4", buildID = 0xaec470 "2008111217", 
    ID = 0xaebc80 "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}", 
    copyright = 0xaebcb0 "Copyright (c) 1998 - 2008 mozilla.org", flags = 6, 
    xreDirectory = 0xaebb80, minVersion = 0xaec490 "1.9.0.4", 
    maxVersion = 0xaec4b0 "1.9.0.4", 
    crashReporterURL = 0xaeba30 "https://crash-reports.mozilla.com/submit", 
    profile = 0x0}, <No data fields>}
	iniFile = {<nsCOMPtr_base> = {mRawPtr = 0xaebce0}, <No data fields>}
	localIniFile = {<nsCOMPtr_base> = {
    mRawPtr = 0xaebce0}, <No data fields>}
	parser = {
  mSections = {<nsBaseHashtable<nsDepCharHashKey, nsAutoPtr<nsINIParser_internal::INIValue>, nsINIParser_internal::INIValue*>> = {<nsTHashtable<nsBaseHashtableET<nsDepCharHashKey, nsAutoPtr<nsINIParser_internal::INIValue> > >> = {
---Type <return> to continue, or q <return> to quit---
        mTable = {ops = 0x7f0b07a31d80, data = 0x0, hashShift = 28, 
          maxAlphaFrac = 192 '�', minAlphaFrac = 64 '@', entrySize = 24, 
          entryCount = 1, removedCount = 0, generation = 0, 
          entryStore = 0xaec030 ""}}, <No data fields>}, <No data fields>}, 
  mFileContents = {mRawPtr = 0xaec1c0 "[Build"}}
	i = <value optimized out>
#12 0x0000000000401665 in main (argc=3, argv=0x7fff10ea5ea8)
    at nsXULStub.cpp:364
	iniFile = {<nsCOMPtr_base> = {mRawPtr = 0xaeb750}, <No data fields>}
	appData = {mAppData = 0xaeb820}
	rv = 11450472
	lastSlash = <value optimized out>
	iniPath = "/usr/lib64/firefox-3.0.4/application.ini", '\0' <repeats 4055 times>
	tmpPath = '\0' <repeats 4095 times>
	greDir = "/usr/lib64/xulrunner-1.9\000libxpcom.so", '\0' <repeats 4059 times>
	fileStat = {st_dev = 64771, st_ino = 2798666, st_nlink = 1, 
  st_mode = 33261, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, 
  st_size = 37760, st_blksize = 4096, st_blocks = 80, st_atim = {
    tv_sec = 1229021612, tv_nsec = 0}, st_mtim = {tv_sec = 1226537481, 
    tv_nsec = 0}, st_ctim = {tv_sec = 1228941261, tv_nsec = 0}, __unused = {0, 
    0, 0}}
---Type <return> to continue, or q <return> to quit---
	parser = {
  mSections = {<nsBaseHashtable<nsDepCharHashKey, nsAutoPtr<nsINIParser::INIValue>, nsINIParser::INIValue*>> = {<nsTHashtable<nsBaseHashtableET<nsDepCharHashKey, nsAutoPtr<nsINIParser::INIValue> > >> = {mTable = {ops = 0x608a90, 
          data = 0x0, hashShift = 28, maxAlphaFrac = 192 '�', 
          minAlphaFrac = 64 '@', entrySize = 24, entryCount = 4, 
          removedCount = 0, generation = 0, 
          entryStore = 0xad2250 ""}}, <No data fields>}, <No data fields>}, 
  mFileContents = {mRawPtr = 0xad23e0 "; ***** BEGIN LICENSE BLOCK *****"}}
	retval = <value optimized out>
	kXULFuncs = {{functionName = 0x405c41 "XRE_CreateAppData", 
    function = 0x608ae0}, {functionName = 0x405c53 "XRE_FreeAppData", 
    function = 0x608ae8}, {functionName = 0x405c63 "XRE_main", 
    function = 0x608af0}, {functionName = 0x0, function = 0x0}}
	kProperties = {{property = 0x405c32 "xulrunner", 
    value = 0x405c3c "true"}}
Comment 6 Patrice Dumas 2008-12-15 08:22:29 EST
I cannot reproduce it. If you want to move this forward, you should work with upstream, that is, try to reproduce with the bzr version, and if you reproduce it, put it in upstream bugzilla.
Comment 7 Stas Sergeev 2008-12-15 13:27:58 EST
OK, I might have been brain-dead for
not mentioning that I have the FlashBlock
plugin installed. It seems that this is
what provokes the crashes. But the
FlashBlock plugin is not the crasher by
itself. It doesn't execute any code
natively, it only uses xul and js AFAIK.
I've also found the reports that it makes
the adobe flash plugin 9 to crash, but
10 is not crashing. So somehow it provokes
the crash in the gnash-plugin too (or
maybe even directly in gecko).
Could you please see if you can reproduce
the problem with the flashblock-1.5.7
installed?
Comment 8 Patrice Dumas 2008-12-16 05:38:50 EST
How is the flashblock package called?
Comment 9 Stas Sergeev 2008-12-16 06:14:52 EST
It is probably not the part of fedora at
the moment. You can get it from here:
http://downloads.mozdev.org/flashblock/flashblock-1.5.7.1.xpi
Comment 10 Stas Sergeev 2008-12-20 14:08:02 EST
How goes the reproducing?
Btw, swfdec-mozilla does not crash.
Neither does it even require the flashblock -
nice! I'll probably stick with swfdec
then.
Comment 11 Patrice Dumas 2008-12-20 17:17:28 EST
I didn't tried to reproduce it. I am not very comfortable with using an extension which is not packaged.

Besides, I am not sure that it would be that useful, because
* firefox integration is being reworked currently
* there is already a way to do that natively in gnash, by setting, in .gnashrc
set startStopped on

Given that there is a workaround and fixing it in fedora won't profit to upstream, I don't think that much time should be involved here. I think it would be better to try to reproduce the issue with the upstream bzr checkout.

In any case I am not the gnash maintainer anymore, so let's see what Kevin says.
Comment 12 Kevin Kofler 2008-12-20 17:28:42 EST
Looks like a problem with event loop processing, probably an event handler which is still registered, but no longer valid (maybe the containing class has been destroyed, or the event loop it has been registered in - the latter is something which happened to work in old GTK+ versions (event handlers could be registered in one event loop and used in another), but not in the current one (now event handlers only work in the event loop they were registered in and its subordinate event loops, once the event loop the event was registered in is destroyed, the handler becomes invalid)).

IMHO this should be reported to the upstream gnash bug tracker, it's certainly not a Fedora-specific issue.
Comment 13 Bug Zapper 2009-11-18 03:56:31 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Bug Zapper 2009-12-18 01:55:36 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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