Closed Bug 536020 Opened 16 years ago Closed 15 years ago

Firefox 3.6b5 Crash Report [@ nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) ] [@ @0x0 | nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) ]

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
1.9.2 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking1.9.2 .4+, status1.9.2 .4-fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking1.9.2 --- .4+
status1.9.2 --- .4-fixed

People

(Reporter: chofmann, Assigned: benjamin)

References

Details

(Keywords: crash, regression, Whiteboard: [crashkill][3.6.x] [qa-examined-192] [qa-noaction-192])

Crash Data

Attachments

(1 file, 1 obsolete file)

Remove nsPluginInstanceTagList.mLast, rev. 1
5.43 KB, patch
jaas
: review+
beltzner
: approval1.9.2.4+
Details | Diff | Splinter Review
It looks like there is a volume increase in this signature after the first full day of 3.6b5 all 219740 35 0.000159279 3.0.15 11190 1 8.93655e-05 3.0.16 27771 1 3.60088e-05 3.5.5 30286 0 3.5.6 94168 0 3.6b5 7850 32 0.00407643 3.6b4 13893 0 3.6b3 651 0 3.6b2 733 0 3.6b1 2174 0 currently ranked the #35 top crash after a couple of days of 3.6b5 stack looks like Frame Module Signature [Expand] Source 0 @0x76726553 1 xul.dll nsPluginStreamListenerPeer::SetUpStreamListener modules/plugin/base/src/nsPluginHost.cpp:2390 2 xul.dll nsPluginStreamListenerPeer::OnStartRequest modules/plugin/base/src/nsPluginHost.cpp:2011 3 xul.dll nsObjectLoadingContent::OnStartRequest content/base/src/nsObjectLoadingContent.cpp:617 more reports at http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=nsPluginStreamListenerPeer%3A%3ASetUpStreamListener%28nsIRequest*%2C%20nsIURI*%29&version=Firefox%3A3.6b5 source lines don't match up with the changes made but I'm wondering if this could be a side affect of 777f1168748 2009-12-02 22:33 -0800 Josh Aas - Fixing bug 520639. Make plugin library unloading independent of the lifetime of nsPluginTag objects. Patch and reviews by jst@mozilla.com and joshmoz@gmail.com, a=blocking1.9.2+
Flags: blocking1.9.2?
Keywords: crash
Whiteboard: [crashkill]
is the signature [@ @0x0 | nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) ] related? Frame Module Signature [Expand] Source 0 @0x0 1 xul.dll nsPluginStreamListenerPeer::SetUpStreamListener modules/plugin/base/src/nsPluginHost.cpp:2390 2 xul.dll nsPluginNativeWindowWin::CallSetWindow modules/plugin/base/src/nsPluginNativeWindowWin.cpp:514 3 xul.dll nsPluginStreamListenerPeer::OnStartRequest modules/plugin/base/src/nsPluginHost.cpp:2011 4 xul.dll nsObjectLoadingContent::OnStartRequest content/base/src/nsObjectLoadingContent.cpp:617 its currently ranked #33 in early 3.6b5 data and looks like it might be new in b5.
Summary: Firefox 3.6b5 Crash Report [@ nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) ] → Firefox 3.6b5 Crash Report [@ nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) ] [@ @0x0 | nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) ]
We're not at the point where we're going to add blockers based on maybes and looks likes. If it pops up to the top then please renominate. We've got to get this release done, and we're not going to get to zero crashers :(
Flags: blocking1.9.2? → blocking1.9.2-
another likely regression from plugin unloading or other changes in beta5 date nsPluginStreamListenerPeer::SetUpStreamListenercrashes 20091201-crashdata 35 nsPluginStreamListenerPeer::SetUpStreamListener 20091202-crashdata 24 nsPluginStreamListenerPeer::SetUpStreamListener 20091203-crashdata 22 nsPluginStreamListenerPeer::SetUpStreamListener 20091204-crashdata 20 nsPluginStreamListenerPeer::SetUpStreamListener 20091205-crashdata 14 nsPluginStreamListenerPeer::SetUpStreamListener 20091206-crashdata 19 nsPluginStreamListenerPeer::SetUpStreamListener 20091207-crashdata 31 nsPluginStreamListenerPeer::SetUpStreamListener 20091208-crashdata 20 nsPluginStreamListenerPeer::SetUpStreamListener 20091209-crashdata 22 nsPluginStreamListenerPeer::SetUpStreamListener 20091210-crashdata 16 nsPluginStreamListenerPeer::SetUpStreamListener 20091211-crashdata 32 nsPluginStreamListenerPeer::SetUpStreamListener 20091212-crashdata 22 nsPluginStreamListenerPeer::SetUpStreamListener 20091213-crashdata 25 nsPluginStreamListenerPeer::SetUpStreamListener 20091214-crashdata 32 nsPluginStreamListenerPeer::SetUpStreamListener 20091215-crashdata 33 nsPluginStreamListenerPeer::SetUpStreamListener 20091216-crashdata 22 nsPluginStreamListenerPeer::SetUpStreamListener 20091217-crashdata 39 nsPluginStreamListenerPeer::SetUpStreamListener 20091218-crashdata 67 nsPluginStreamListenerPeer::SetUpStreamListener 20091219-crashdata 99 nsPluginStreamListenerPeer::SetUpStreamListener 20091220-crashdata 138 nsPluginStreamListenerPeer::SetUpStreamListener
#33 yesterday #25 today
the combined signatures #25 nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) and #34 @0x0 | nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) do put this in the top 10. jst and josh ought to have a look at this before we ship.
Flags: blocking1.9.2- → blocking1.9.2?
jst is out on holiday; cc'ing sicking, instead.
I'm heading on vacation too so won't be able to look at this more than at a glance :( Looks like we're calling a function on a dangling pointer here: http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/5ba5f965c12b/modules/plugin/base/src/nsPluginHost.cpp#l2390 Glancing over the code it looks like we're doing the refcounting correct. Though there's a lot of manual refcounting going on in this code so I wouldn't be surprised if it's going wrong somewhere.
I'm grudgingly happy to clean this up post RC, even if that means in a 3.6.1. Gotta ship.
Flags: blocking1.9.2? → blocking1.9.2-
Whiteboard: [crashkill] → [crashkill][3.6.x]
Any chance that this will be resolved by the fix in bug 535898?
I doubt it, but given the lack of understanding of what happens there so far, I wouldn't rule it out either.
I can reproduce this crash on Windows by uninstalling "Apple Application Support" that gets installed with Quicktime and then trying to play content using the quicktime plugin (e.g. apple.com/trailers). Note that uninstalling Application Support breaks quicktime player, iTunes, etc.
If you apply this patch to an m-c build with --enable-ipc, and set dom.ipc.plugins.enabled=true, then visit http://www.macloo.com/examples/flash/animation/martini.htm, this crash is reliably triggered: (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007ffff618d168 in nsNPAPIPluginStreamListener::OnStartBinding (this=0x82aee0, pluginInfo=0x17bd1e0) at /home/cjones/mozilla/mozilla-central/modules/plugin/base/src/nsNPAPIPluginInstance.cpp:366 #2 0x00007ffff61980b5 in nsPluginStreamListenerPeer::SetUpStreamListener (this=0x17bd120, request=0x17bd740, aURL=0x179c230) at /home/cjones/mozilla/mozilla-central/modules/plugin/base/src/nsPluginHost.cpp:1624 #3 0x00007ffff6196ab9 in nsPluginStreamListenerPeer::OnStartRequest (this=0x17bd120, request=0x17bd740, aContext=0x0) at /home/cjones/mozilla/mozilla-central/modules/plugin/base/src/nsPluginHost.cpp:1253 #4 0x00007ffff5379d34 in nsHttpChannel::CallOnStartRequest (this=0x17bd6f0) at /home/cjones/mozilla/mozilla-central/netwerk/protocol/http/src/nsHttpChannel.cpp:839 #5 0x00007ffff537a929 in nsHttpChannel::ProcessNormal (this=0x17bd6f0) at /home/cjones/mozilla/mozilla-central/netwerk/protocol/http/src/nsHttpChannel.cpp:1145 #6 0x00007ffff537a358 in nsHttpChannel::ProcessResponse (this=0x17bd6f0) at /home/cjones/mozilla/mozilla-central/netwerk/protocol/http/src/nsHttpChannel.cpp:1014 #7 0x00007ffff5389fea in nsHttpChannel::OnStartRequest (this=0x17bd6f0, request=0x17bc3b0, ctxt=0x0) at /home/cjones/mozilla/mozilla-central/netwerk/protocol/http/src/nsHttpChannel.cpp:5162 #8 0x00007ffff52933a4 in nsInputStreamPump::OnStateStart (this=0x17bc3b0) at /home/cjones/mozilla/mozilla-central/netwerk/base/src/nsInputStreamPump.cpp:439 #9 0x00007ffff52931d4 in nsInputStreamPump::OnInputStreamReady (this=0x17bc3b0, stream=0x17be4f8) at /home/cjones/mozilla/mozilla-central/netwerk/base/src/nsInputStreamPump.cpp:395 #10 0x00007ffff661cb7b in nsInputStreamReadyEvent::Run (this=0x17bf0f0) at /home/cjones/mozilla/mozilla-central/xpcom/io/nsStreamUtils.cpp:112 #11 0x00007ffff664a3e1 in nsThread::ProcessNextEvent (this=0x6c58f0, mayWait=0, result=0x7fffffffde4c) at /home/cjones/mozilla/mozilla-central/xpcom/threads/nsThread.cpp:527 #12 0x00007ffff65da870 in NS_ProcessNextEvent_P (thread=0x6c58f0, mayWait=0) at nsThreadUtils.cpp:250 #13 0x00007ffff64ab5c8 in mozilla::ipc::MessagePump::Run (this=0x6c4b10, aDelegate=0x6b3bb0) at /home/cjones/mozilla/mozilla-central/ipc/glue/MessagePump.cpp:118 #14 0x00007ffff654b5c1 in MessageLoop::RunInternal (this=0x6b3bb0) at /home/cjones/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:211 #15 0x00007ffff654b546 in MessageLoop::RunHandler (this=0x6b3bb0) at /home/cjones/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:194 #16 0x00007ffff654b4d7 in MessageLoop::Run (this=0x6b3bb0) at /home/cjones/mozilla/mozilla-central/ipc/chromium/src/base/message_loop.cc:168 #17 0x00007ffff635a21d in nsBaseAppShell::Run (this=0xcad1b0) at /home/cjones/mozilla/mozilla-central/widget/src/xpwidgets/nsBaseAppShell.cpp:174 #18 0x00007ffff60b8e15 in nsAppStartup::Run (this=0xd2e6f0) at /home/cjones/mozilla/mozilla-central/toolkit/components/startup/src/nsAppStartup.cpp:182 #19 0x00007ffff517298a in XRE_main (argc=3, argv=0x7fffffffe7e8, aAppData=0x60a160) at /home/cjones/mozilla/mozilla-central/toolkit/xre/nsAppRunner.cpp:3476 #20 0x0000000000401302 in main (argc=4, argv=0x7fffffffe7e8) at /home/cjones/mozilla/mozilla-central/browser/app/nsBrowserApp.cpp:158 on both windows and linux. bsmedberg and I are investigating.
valgrind sez ==2545== Invalid read of size 8 ==2545== at 0x662C136: nsNPAPIPluginStreamListener::OnStartBinding(nsIPluginStreamInfo*) (nsNPAPIPluginInstance.cpp:366) ==2545== by 0x66370B4: nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) (nsPluginHost.cpp:1624) ==2545== by 0x6635AB8: nsPluginStreamListenerPeer::OnStartRequest(nsIRequest*, nsISupports*) (nsPluginHost.cpp:1253) ==2545== by 0x5818D33: nsHttpChannel::CallOnStartRequest() (nsHttpChannel.cpp:839) ==2545== by 0x5819928: nsHttpChannel::ProcessNormal() (nsHttpChannel.cpp:1145) ==2545== by 0x5819357: nsHttpChannel::ProcessResponse() (nsHttpChannel.cpp:1014) ==2545== by 0x5828FE9: nsHttpChannel::OnStartRequest(nsIRequest*, nsISupports*) (nsHttpChannel.cpp:5162) ==2545== by 0x57323A3: nsInputStreamPump::OnStateStart() (nsInputStreamPump.cpp:439) ==2545== by 0x57321D3: nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (nsInputStreamPump.cpp:395) ==2545== by 0x6ABBB7A: nsInputStreamReadyEvent::Run() (nsStreamUtils.cpp:112) ==2545== by 0x6AE93E0: nsThread::ProcessNextEvent(int, int*) (nsThread.cpp:527) ==2545== by 0x6A7986F: NS_ProcessNextEvent_P(nsIThread*, int) (nsThreadUtils.cpp:250) ==2545== Address 0x1a8ccc28 is 56 bytes inside a block of size 160 free'd ==2545== at 0x4C24A7A: operator delete(void*) (vg_replace_malloc.c:346) ==2545== by 0x6622CB2: nsNPAPIPlugin::~nsNPAPIPlugin() (nsNPAPIPlugin.cpp:292) ==2545== by 0x66228C8: nsNPAPIPlugin::Release() (nsNPAPIPlugin.cpp:221) ==2545== by 0x693858D: nsRunnableMethod<nsNPAPIPlugin, void>::~nsRunnableMethod() (nsThreadUtils.h:311) ==2545== by 0x6A79309: nsRunnable::Release() (nsThreadUtils.cpp:55) ==2545== by 0x5621411: nsCOMPtr<nsIRunnable>::~nsCOMPtr() (nsCOMPtr.h:510) ==2545== by 0x6AE9435: nsThread::ProcessNextEvent(int, int*) (nsThread.cpp:532) ==2545== by 0x6A7986F: NS_ProcessNextEvent_P(nsIThread*, int) (nsThreadUtils.cpp:250) ==2545== by 0x694A5C7: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (MessagePump.cpp:118) ==2545== by 0x69EA5C0: MessageLoop::RunInternal() (message_loop.cc:211) ==2545== by 0x69EA545: MessageLoop::RunHandler() (message_loop.cc:194) ==2545== by 0x69EA4D6: MessageLoop::Run() (message_loop.cc:168) ==2545== ==2545== Jump to the invalid address stated on the next line ==2545== at 0x0: ??? ==2545== by 0x66370B4: nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) (nsPluginHost.cpp:1624) ==2545== by 0x6635AB8: nsPluginStreamListenerPeer::OnStartRequest(nsIRequest*, nsISupports*) (nsPluginHost.cpp:1253) ==2545== by 0x5818D33: nsHttpChannel::CallOnStartRequest() (nsHttpChannel.cpp:839) ==2545== by 0x5819928: nsHttpChannel::ProcessNormal() (nsHttpChannel.cpp:1145) ==2545== by 0x5819357: nsHttpChannel::ProcessResponse() (nsHttpChannel.cpp:1014) ==2545== by 0x5828FE9: nsHttpChannel::OnStartRequest(nsIRequest*, nsISupports*) (nsHttpChannel.cpp:5162) ==2545== by 0x57323A3: nsInputStreamPump::OnStateStart() (nsInputStreamPump.cpp:439) ==2545== by 0x57321D3: nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (nsInputStreamPump.cpp:395) ==2545== by 0x6ABBB7A: nsInputStreamReadyEvent::Run() (nsStreamUtils.cpp:112) ==2545== by 0x6AE93E0: nsThread::ProcessNextEvent(int, int*) (nsThread.cpp:527) ==2545== by 0x6A7986F: NS_ProcessNextEvent_P(nsIThread*, int) (nsThreadUtils.cpp:250) ==2545== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==2545==
In the particular case of the crash with OOPP, we have a special PluginCrashed() event that fires after the plugin process crashes. If I call nsNPAPIPluginInstance::Stop() (which ends up cancelling timers etc.) on all instances of the crashed nsNPAPIPlugin, this particular crash goes away. But if the OOPP crash is indeed a symptom of the same bug as the in-process crash, then the PluginCrashed() event must not be the right place to Stop() the instances. jst, josh, any advice? Maybe ~nsNPAPIPlugin()?
I suspect that in the non-OOPP case, we kill off the nsNPAPIPlugin in the process of reloading plugins (remove and re-create its plugin tag) but leave plugin instances around in a non-stopped state. Hard to prove, though!
(In reply to comment #12) > I can reproduce this crash on Windows by uninstalling "Apple Application > Support" that gets installed with Quicktime and then trying to play content > using the quicktime plugin (e.g. apple.com/trailers). > > Note that uninstalling Application Support breaks quicktime player, iTunes, > etc. This is most likely bug 535898.
I've got a fix for the OOPP bug, but it won't help a bit with this one. Spun off bug 538532 for the OOPP issue.
(In reply to comment #11) > I doubt it, but given the lack of understanding of what happens there so far, I > wouldn't rule it out either. As far as I can see we have had only 1 report on this signature in 3.6 rc1 http://crash-stats.mozilla.com/report/index/b89a6a45-d40c-4a61-9fe0-8c2422100109 150k plus users yesterday. It looks like somehow this has been fixed.
Sweet! In that case, I bet the fix for bug 535898 fixed this as well.
some early quick looking at the small amount of 3.6.3plugin1 data seems to show a higher than ordinary number of these crashes based on the number of users that have those test builds. need to do some double checking to confirm http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=nsPluginStreamListenerPeer%3A%3ASetUpStreamListener%28nsIRequest&date=&range_value=1&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=nsPluginStreamListenerPeer%3A%3ASetUpStreamListener%28nsIRequest*%2C%20nsIURI*%29 we should check that Lortentz hasn't forgotten or stomped on work in 533898 or what ever may have reduced the volume in 3.6rc1
blocking1.9.2: --- → ?
Josh, can you look and see whether I merged anything incorrectly in Lorentz, and look through the crash reports to see if you can find STR?
Assignee: nobody → joshmoz
I diff'd 1.9.2->1.9.3 for stream-related files in modules/plugin and didn't see anything significantly different for streams except bug 548441 is on trunk and not branch. My comment #9 here indicated that this happened to people installing Silverlight. The query in that comment no longer shows that, now all the comments seem to be about Flash games on Facebook.
Possibly-relevant comments: "I would almost guess you already have lots of those reports, but just in case ... this crash happened when clicking on the "reload page" link after a plugin crash (silverlight in this case). the strange thing is, silverlight never crashed for me before this beta, neither did firefox. so for now this new feature is counter-productive ;)" "Started to play a RealPlayer video"
urls are mostly facebook apps. 3 http://apps.facebook.com/onthefarm/index.php?ref=tab 3 http://apps.facebook.com/onthefarm/index.php 2 http://apps.facebook.com/cafeworld/?ref=bookmark 1 http://apps.facebook.com/mallworldgame/ 1 http://apps.facebook.com/coasterkingdom/index.php?src=xpromo&aff=zbar&crt=petville 1 http://apps.facebook.com/cafeworld/ 3.6.4 early data looks the same with a marked increase. there are about 160k users on 3.6.4 yesterday, and 65million on 3.6.3 so it could turn out to be a 3 or 4x volume regression. checking --- nsPluginStreamListenerPeer::SetUpStreamListener 20100419-crashdata.csv found in: 3.6.4 3.6.3plugin1 3.6.3 3.7a4 3.6b5 3.5.6 3.0b1 3.0.3 3.0.10 release total-crashes nsPluginStreamListenerPeer::SetUpStreamListener crashes pct. all 366784 34 9.26976e-05 3.6.4 11871 17 0.00143206 3.6.3plugin1 728 4 0.00549451 3.6.3 250294 4 1.59812e-05
So I loaded one of the minidumps into MSVC, and the stack is in fact kinda different: 6d6f632e() > xul.dll!nsNPAPIPluginStreamListener::OnStartBinding(nsIPluginStreamInfo * pluginInfo=0x09305e14) Line 373 + 0x42 bytes C++ xul.dll!nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest * request=0x0aaccafc, nsIURI * aURL=0x0aaccafc) Line 2227 C++ xul.dll!nsPluginStreamListenerPeer::OnStartRequest(nsIRequest * request=0x0aaccadc, nsISupports * aContext=0x0a449500) Line 1844 C++ ... xul.dll!nsStreamListenerTee::OnStartRequest(nsIRequest * request=0x0aaccafc, nsISupports * context=0x00000000) Line 51 + 0xd bytes C++ xul.dll!nsHttpChannel::CallOnStartRequest() Line 850 C++ We're actually crashing on this line: NS_TRY_SAFE_CALL_RETURN(error, (*callbacks->newstream)(npp, (char*)contentType, &mNPStream, seekable, &streamType), mInst->mLibrary, mInst); on the call instruction. So, assuming that the nsPluginStreamListenerPeer and nsNPAPIPluginStream listener are both still good objects: mInst is probably a valid live pointer, since we addref it in the nsNPAPIPluginStreamListener constructor. mInst->mCallbacks is a reference to memory owned by nsNPAPIPlugin, and is probably dead (if this plugin crashed: otherwise we wouldn't ever be destroying the nsNPAPIPlugin until the app shuts down). When an instance is destroyed (either normally, or from a plugin-crashed notification), nsNPAPIPluginStreamListener::CleanUpStream is called. But as far as I can tell, this doesn't actually cancel the network stream. nsNPAPIPluginStreamListener::OnStartBinding does have a check for mInst->CanFireNotifications(), and if the plugin instance is truly dead, this should return false. I wonder if the plugin-crash notification is skipping some of the destruction steps. It should call nsNPAPIPluginInstance::Stop, which should clean up the streams.
Blocking based on comment 24
blocking1.9.2: ? → .4+
Keywords: regression
Right now I'm thinking that somehow we're not stopping all the plugin instances when a plugin "crashes". My current theory is that the plugininstancetag list iteration at http://mxr.mozilla.org/mozilla1.9.2/source/modules/plugin/base/src/nsPluginHost.cpp#6281 Is re-entering, removing the instance tag from and causing us to stop iteration. Josh, do you know if nsIPluginInstance::Stop() can re-enter and remove plugin instances mid-call like that?
I've caught this in recording. I created a page which just calls navigator.plugins.refresh() over and over in a loop, then killed of a plugin-runtime process and this eventually crashed.
Assignee: joshmoz → benjamin
I think the conditions for this bug are: 1) at least two plugins are loaded 2) navigator.plugins.refresh() is called, probably after a plugin has crashed Pretty sure the plugininstancetag list is getting out of sync with reality at some point.
I've figured this out: nsPluginHost::PluginCrashed removes things from the nsPluginInstanceTagList, but doesn't reset mLast correctly, which leads to mLast being disconnected from mFirst. After a crash, then, any call to navigator.plugins.refresh() will unload the new nsNPAPIPlugin, and cause those plugin instances to be bad. This leads to a bunch of different crashes, depending on when free memory gets stomped. This code has changed a lot on trunk, so this fix is going to be branch-only: I'm just going to remove mLast from nsPluginInstanceTagList, since it's not actually a doubly-linked list which needs last-tracking.
Attachment #420623 - Attachment is obsolete: true
Attachment #441289 - Flags: review?(joshmoz)
Version: Trunk → 1.9.2 Branch
Attachment #441289 - Attachment filename: nsPluginInstanceTagList-mPrev → nsPluginInstanceTagList-mLast
Bug 535643 probably fixed this on trunk.
Attachment #441289 - Attachment description: Remove nsPluginInstanceTagList.mPrev, rev. 1 → Remove nsPluginInstanceTagList.mLast, rev. 1
Attachment #441289 - Flags: review?(joshmoz) → review+
Comment on attachment 441289 [details] [diff] [review] Remove nsPluginInstanceTagList.mLast, rev. 1 This is fairly low-risk: the only logical change is that new plugin instances are added to the front of mPluginInstanceTagList, instead of the back, but that shouldn't affect anything.
Attachment #441289 - Flags: approval1.9.2.4?
Comment on attachment 441289 [details] [diff] [review] Remove nsPluginInstanceTagList.mLast, rev. 1 a=beltzner, please land on mozilla-1.9.1 default, mozilla 1.9.2 default AND mozilla-1.9.2 GECKO1924_20100413_RELBRANCH
Attachment #441289 - Flags: approval1.9.2.4? → approval1.9.2.4+
Err, bad paste, please do not land on 1.9.1 :/
Whiteboard: [crashkill][3.6.x] → [crashkill][3.6.x] [qa-examined] [qa-ntd]
We never came up with a repro case to clearly cause this issue, did we?
The steps I used to reproduce were: 1. Tab A, load http://office.smedbergs.us/refresh-plugins.html 2. Tab B, Load hulu 3. kill plugin-runtime 4. Reload hulu 5. Hit the refreshPlugins button in tab A Repeat steps 3-5 until something bad happens. Usually happens pretty quickly.
Whiteboard: [crashkill][3.6.x] [qa-examined] [qa-ntd] → [crashkill][3.6.x] [qa-examined-192] [qa-ntd]
also check for the absence of signature from Bug 563016 when verifying this bug. [@ nsNPAPIPluginInstance::GetJSObject(JSContext*, JSObject**) ]
also make sure Bug 563011 - Firefox Crash [@ nsObjectFrame::PaintPlugin(nsIRenderingContext&, nsRect const&, nsRect const&) ] has gone away when verifying this bug.
Whiteboard: [crashkill][3.6.x] [qa-examined-192] [qa-ntd] → [crashkill][3.6.x] [qa-examined-192] [qa-noaction-192]
Is this issue supposed to be fixed in 3.6.6? Because i've been getting crashes in 3.6.6 with Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 ( .NET CLR 3.5.30729) under the following ID: http://crash-stats.mozilla.com/report/index/bp-6c22c62e-20d7-4c15-bd6a-55e522100713
that's different. this was a null pointer crash. yours is probably a library got unloaded crash.
Crash Signature: [@ nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) ] [@ @0x0 | nsPluginStreamListenerPeer::SetUpStreamListener(nsIRequest*, nsIURI*) ]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: