Closed Bug 539775 Opened 12 years ago Closed 12 years ago

Fennec crashes loading


(Firefox for Android Graveyard :: General, defect)

Fennec 1.1
Not set



Tracking Status
fennec 1.0+ ---


(Reporter: pavlov, Assigned: dougt)




(3 obsolete files)

Goes away if I disable plugins
Assignee: nobody → mozbugz
tracking-fennec: --- → 1.0+
Duplicate of this bug: 540050
#0  0x57420000 in ?? ()
#1  0x42ea8d44 in ns_if_addref<nsIPluginInstanceOwner*> (expr=<value optimized out>) at ../../../../dist/include/nsISupportsUtils.h:114
#2  0x42ea5c00 in nsNPAPIPluginInstance::GetOwner (this=0x4b485c00, aOwner=0xbe8a0754)
    at /home/dougt/mobile/mozilla-1.9.2/modules/plugin/base/src/nsNPAPIPluginInstance.cpp:2047
#3  0x42eaac38 in nsPluginHost::DoURLLoadSecurityCheck (this=<value optimized out>, aInstance=0x4b485c00, 
    aURL=0x4a76dac0 <Address 0x4a76dac0 out of bounds>) at /home/dougt/mobile/mozilla-1.9.2/modules/plugin/base/src/nsPluginHost.cpp:5717
#4  0x42eb1f6c in nsPluginHost::GetURLWithHeaders (this=Cannot access memory at address 0xbe8a0778
) at /home/dougt/mobile/mozilla-1.9.2/modules/plugin/base/src/nsPluginHost.cpp:2785
#5  0x42eb2128 in nsPluginHost::GetURL (this=0x467dd2f0, pluginInst=0xbe8a0754, url=0x4a76dac0 <Address 0x4a76dac0 out of bounds>, 
    target=0x467dd358 <Address 0x467dd358 out of bounds>, streamListener=Cannot access memory at address 0xbe8a0870
    at /home/dougt/mobile/mozilla-1.9.2/modules/plugin/base/src/nsPluginHost.cpp:2755
#6  0x42ea3b70 in MakeNewNPAPIStreamInternal (npp=<value optimized out>, relativeURL=Cannot access memory at address 0xbe8a086c
    at /home/dougt/mobile/mozilla-1.9.2/modules/plugin/base/src/nsNPAPIPlugin.cpp:912
#7  0x42ea3df4 in _geturlnotify (npp=Cannot access memory at address 0xbe8a08f0
) at /home/dougt/mobile/mozilla-1.9.2/modules/plugin/base/src/nsNPAPIPlugin.cpp:984
#8  0x48f2c1c0 in ?? () from /usr/lib/browser/plugins/
#9  0x48f2c1c0 in ?? () from /usr/lib/browser/plugins/

plugin instance (nsIPluginInstance) is created
plugin owner (nsIPluginInstanceOwner) owns the instance
instances has a back pointer to the plugin own

nsObjectFrame creates the plugin owner (nsIPluginInstanceOwner)

The crash happens because the Instance is deleted, and plugin still calls to it.

Which implies the plugin owner has gone away prematurely?
Would the fix for bug 533030 help here?
I really wish it did. :(

What I see is that we call stop() on the plugin instance and that is successful (stop on the plugin is called).  We then tear down the plugin instance.  However, a few moments later, either invalidateRect or getvalue or geturl will be called on the destroyed plugin instance.

For example, here is a simple log of what I am seeing:

nsNPAPIPluginInstance->GetValue 0x47d62a00
nsNPAPIPluginInstance->GetValue 0x47d0b500
nsNPAPIPluginInstance->GetValue 0x47d0b500
nsNPAPIPluginInstance->Stop 0x47d0b500
  calling destory!
  returned ok!!
nsNPAPIPluginInstance->GetValue 0x47d0b500
Segmentation fault

Is the expectation that after Stop is called, the plugin should NOT call us back?
Yes. Once NPP_Destroy has been called the plugin should not be making further calls, and we shouldn't be calling anything on that instance.
another crash

#0  gfxTextRun::CompressedGlyph::IsClusterStart (this=0x3eb57d98) at ../../dist/include/gfxFont.h:1342
#1  0x430e1398 in gfxTextRun::SetPotentialLineBreaks (this=0x448796a0, aStart=3196811688, aLength=1149736608, aBreakBefore=0x433e9998 "\244h\16C@h\16C(\23\16CP\25\16C\360\61\16C\24b\16C", 
    aRefContext=0xbe8b795c) at /home/dougt/mobile/mozilla-1.9.2/gfx/thebes/src/gfxFont.cpp:1898
#2  0x430625c8 in ~nsCOMPtr_base (this=0xbe8b795c) at nsCOMPtr.cpp:81
#3  0x4283acb4 in ~nsCOMPtr (this=0x3eb57d98) at ../../dist/include/nsCOMPtr.h:469
#4  0x42ea5cb0 in nsNPAPIPluginInstance::InvalidateRect (this=<value optimized out>, invalidRect=0xbe8b79a8) at /home/dougt/mobile/mozilla-1.9.2/modules/plugin/base/src/nsNPAPIPluginInstance.cpp:1978
#5  0x42ea1fc8 in _invalidaterect (npp=<value optimized out>, invalidRect=0xbe8b79a8) at /home/dougt/mobile/mozilla-1.9.2/modules/plugin/base/src/nsNPAPIPlugin.cpp:1272
#6  0x4b22c458 in ?? () from /usr/lib/browser/plugins/

the nsNPAPIPluginInstance has since been destroyed.
this is the worst thing I have thought about adding to the tree.  However, it seems to prevent us from crashing from the buggy flash.
Attachment #422457 - Flags: review?(joshmoz)
How bad is the leak ?
better than a crash, but still crappy.
Attached patch patch v.2 (obsolete) — Splinter Review
printfs need to be removed.
Attachment #422457 - Attachment is obsolete: true
Attachment #422457 - Flags: review?(joshmoz)
Attachment #422494 - Flags: review?(joshmoz)
Attached patch patch v.3 (obsolete) — Splinter Review
better macros.  printf's can be removed before pushing.
Attachment #422494 - Attachment is obsolete: true
Attachment #422573 - Flags: review?(joshmoz)
Attachment #422494 - Flags: review?(joshmoz)

* i am not convinced any longer that this provides enough protect against the flash crash *

There maybe be a bug in the logic.  Clearly if you allocate over 100 npp's you will crash, but we are crashing well under that limit now.
I'm not seeing a crash on loading nytimes with 11/22 and later nightly builds. Is this fixed?
Closed: 12 years ago
Resolution: --- → FIXED
verified FIXED on builds due to patches in bugs 540795 and 540843 :

Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2pre) Gecko/20100124 Namoroka/3.6pre Fennec/1.0pre
Depends on: 540795, 540843
Attachment #422573 - Attachment is obsolete: true
Attachment #422573 - Flags: review?(joshmoz)
Component: Linux/Maemo → General
OS: All → Linux (embedded)
QA Contact: maemo-linux → general
Hardware: All → ARM
You need to log in before you can comment on or make changes to this bug.