crash [@ nsPluginHostImpl::IsPluginEnabledForExtension]




12 years ago
6 years ago


(Reporter: tracy, Assigned: jst)


(4 keywords)

1.8 Branch
Windows XP
crash, fixed1.8, helpwanted, topcrash+
Bug Flags:
blocking1.7.14 ?
blocking1.8b5 -
blocking1.8rc1 +

Firefox Tracking Flags

(Not tracked)


(crash signature, URL)


(5 attachments)



12 years ago
I can't realiably reproduce this crash but have crashed at least once with build
from 1005 and 1006 at

My crash reprot from this morning
A query for nsPluginHostImpl::IsPluginEnabledForExtension against 1.5 beta

other topsites crash reports mention:

Comment 1

12 years ago
There has been 1000 reports of this crash signature since 9/16.

Nominationg for beta2 and rc1 to get on the radar and let drivers decide which
bucket it belongs
Flags: blocking1.8rc1?
Flags: blocking1.8b5?
almost all (997 out of 1001) reports were from MozillaOrgFirefox15Win322005090806

I'm tempted to think your crash was coincidence (branch nighlyhourly testers are
notorious TB submitters , this one should have been extremely visable)

It started on 20050916, which is odd, it should have started the day the build
was released.

Maybe this was caused by M$ (windows update) or maybe an incredibly popular
extension or plugin that was updated.

I checked the few pages that were mentioned in the bugs and they have different
media (some flash,some wmp, some QT)

Comment 3

12 years ago
I've seen this on trunk nightly builds as well:
Created attachment 198732 [details]
all incidents from fastfind (html/zipped)

for all FF versions
total # of incidents = 7621 crashes
lowest FF version affected = MozillaOrgFirefox10Win322005071605
startdate = 20050916

Comment 5

12 years ago
I couldn't find any recent branch talkback crashes with this stack trace in
talkback. They were all from 9/16 as Peter said. But maybe Talkback is still
behind. Can you do some digging Jay?
Flags: blocking1.8b5? → blocking1.8b5-

Comment 6

12 years ago
I don't see too many of these crashes in 1.5 branch data, but there are enough
for Beta 1 and other recent releases to take a look at this crash for RC1.

I have not been able to reproduce this, but if we can find a way to consistently
see this crash and/or develop a testcase, this should be fixed.
Keywords: helpwanted, qawanted
this may depend on some special plugin being installed, does talkback list the
loaded DLLs?

Comment 8

12 years ago
The DLL info is difficult to pull out of the database, but I can use the
official Talkback report system to see what's there for some of these crashes. 
I will do that next week when I get back from vacation.

Comment 9

12 years ago
I haev these plugins installed when I crashed:
- QuickTime Plug-in 6.5.1
- Shockwave Flash 8.0 r22
- RealPlayer(tm) G2 LiveConnect-Enabled Plug-In (32-bit)
- Macromedia Shockwave for Director Netscape plug-in, version 10.1
- Java(TM) 2 Platform Standard Edition 5.0 Update 4
- Windows Media Player Plug-in Dynamic Link Library

Comment 10

12 years ago
I can reliably reproduce this crash in the following manner.

-Delete the Firefox profile folder
-Launch Fx (don't import anything)
-browse to from the location bar

crash in nsPluginHostImpl::IsPluginEnabledForExtension
TB ID: 10468942

Subsequent attempts to visit result in no crash.
Keywords: qawanted

Comment 11

12 years ago
Created attachment 199065 [details]

Comment 12

12 years ago
Johnny, we've got good steps to reproduce and this is the early favorite in the
topcrash data. Can you take a look?
Flags: blocking1.8rc1? → blocking1.8rc1+
Keywords: topcrash → topcrash+

Comment 13

12 years ago
->jst in hope that he can help us out.
Assignee: nobody → jst


12 years ago
Severity: major → critical

Comment 14

12 years ago
I can't reproduce with the same set of plugins installed but I noticed that
tracy and henrik both have quicktime 6.5.1 where I have the newer 7 version. Can
one of you attach the older version to this bug so I can test that. 

Comment 15

12 years ago
Created attachment 200053 [details]
zip of quicktime plugin files

Comment 16

12 years ago
I use the K-Lite Mega Codec Pack which includes the QT version 6.5.1

Comment 17

12 years ago
Tracy, I still haven't been able to reproduce this crash. I installed the right
quicktime plugin version n' all, and still no go. So it might be some other
plugin that's causing this. From looking at the code involved and your
about:plugins that you attached, I'd suspect it's this plugin:

    File name: npYState.dll

MIME Type 	Description 	Suffixes 	Enabled
application/ 			Yes

The key there is that it doesn't advertise an file suffixes and I think that
might be the problem, but only when the plugins are initially registerd.

Tracy, do you think you could attach that plugin to this bug, or email it
directly to me? I've got an idea on how to fix this, assuming my theory is
right, but I'd like to make sure if possible...

Comment 18

12 years ago
I dont have that plugin install and I can still crash.
All the plugins in about:plugins is "enabled" and it's only the java ones that
lack text in "Suffixes"

Comment 19

12 years ago
I have not been able to reproduce this at all.  I've tried Tracy's steps and a
number of combinations of plugins and extensions, and still no crash...

Tracy:  What extensions do you have installed?  I'm guessing none, since you are
running from a fresh profile directory with nothing imported.  

If anyone that's seeing this crash can post all plugins + extensions that will
be great.

Comment 20

12 years ago
I haven't been able to reproduce this crash the past couple of days at
 I went back and tried with builds I had crashed before. No crash. maybe
changed content?  I've been trying to get to the talkback reports without
success today.  I'd like to find another site that this is reorted to be
crashing on.

jst: do just want the npYState.dll? (this is part of the Yahoo! Messenger

Comment 21

12 years ago
Created attachment 200145 [details] [diff] [review]
Null-check plugins->mExtensionsArray since it can be null.

This should fix this bug. I have yet to see this happen, but I did get the
Yahoo plugin dll from Tracy and with that we end up with a plugin info object
with a null mExtensionsArray member on first startup after installing the
plugin, the reason being that the plugin doesn't support any file extensions at
all. On subsequent startups we'll get this info from the pluginreg.dat file
that we keep, and in that case we'll get a non-null array of extensions (all
empty), so we don't crash in that case, but on first startup when we get this
info from the plugin we do.

So w/o actually seeing this crash, this is the best I've got. Oh, and the first
part of this patch is unrelated, but IMO correct. PL_strncasecmp() will walk
over n characters, or until it reaches a null terminator in the *first*
argument, but it'll happily walk past null terminators in the second argument,
so the order of the arguments is incorrect in that call.

diff -w version to follow.

Comment 22

12 years ago
Created attachment 200146 [details] [diff] [review]
diff -w of the above.
Attachment #200146 - Flags: superreview?(bzbarsky)
Attachment #200146 - Flags: review?(mrbkap)
Comment on attachment 200146 [details] [diff] [review]
diff -w of the above.

Attachment #200146 - Flags: review?(mrbkap) → review+

Comment 24

12 years ago
Comment on attachment 200146 [details] [diff] [review]
diff -w of the above.

>Index: modules/plugin/base/src/nsPluginHostImpl.cpp

>   const char *pExt = aExtensionList;
>   const char *pComma = strchr(pExt, ',');
>   if(pComma == nsnull)
>     return PL_strcasecmp(pExt, aExtension);
>   while(pComma != nsnull)
>   {
>     int length = pComma - pExt;
>-    if(0 == PL_strncasecmp(pExt, aExtension, length))
>+    if(0 == PL_strncasecmp(aExtension, pExt, length))
>       return 0;
>     pComma++;
>     pExt = pComma;
>     pComma = strchr(pExt, ',');
>   }

I'm probably missing something, but I don't see how strlen(aExtension)
could ever be less than length.

The other part of this change looks nice and consistent with the rest
of the code that null checks mExtensionsArray before dereferencing it.



12 years ago
Attachment #200146 - Flags: superreview?(bzbarsky) → superreview+

Comment 25

12 years ago
> >   const char *pExt = aExtensionList;

nevermind, i kept reading this as:

      const char *pExt = aExtension;

which explains my crazy comment about strlen(aExtension).

Comment 26

12 years ago
Fix checked in on the trunk.
Last Resolved: 12 years ago
Resolution: --- → FIXED


12 years ago
Attachment #200146 - Flags: approval1.8rc1?


12 years ago
Attachment #200146 - Flags: approval1.8rc1? → approval1.8rc1+

Comment 27

12 years ago
Fixed on the 1.8 branch now too.
Keywords: fixed1.8

Comment 28

12 years ago
*** Bug 313905 has been marked as a duplicate of this bug. ***

Comment 29

12 years ago
This might be a major topcrasher for Mozilla Suite 1.7.13.  It is #1 on the list so far ( and although the stacks vary in, the stack signature is the same.

I wonder if this null check will fix the crash on the 1.7 branch. 

Flags: blocking1.7.14?
Crash Signature: [@ nsPluginHostImpl::IsPluginEnabledForExtension]
You need to log in before you can comment on or make changes to this bug.