444711 - Trying to check IsPluginEnabledForType() during ScanPluginsDirectoryList() can lead to infinite loop

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[Mike Hommey [:glandium]]

It can, and it does, with the amd64 (and probably x86) blackdown java plugin 1.4. You can get this java plugin on ubuntu: http://packages.ubuntu.com/gutsy/j2re1.4

The reason why it happens can be seen in the stacktrace:
#8  0x00007f1f34d474b5 in nsPluginHostImpl::ScanPluginsDirectory (this=0x7f1f258cdde0, 
    pluginsDir=<value optimized out>, compManager=<value optimized out>, aCreatePluginList=1, 
    aPluginsChanged=0x7fff3ef1a784, checkForUnwantedPlugins=0) at nsPluginHostImpl.cpp:5181
#9  0x00007f1f34d4773f in nsPluginHostImpl::ScanPluginsDirectoryList (this=0x7f1f258cdde0, dirEnum=0x7f1f23bfad60, 
    compManager=0x7f1f28212170, aCreatePluginList=1, aPluginsChanged=0x7fff3ef1a838, checkForUnwantedPlugins=0)
    at nsPluginHostImpl.cpp:5284
#10 0x00007f1f34d4789a in nsPluginHostImpl::FindPlugins (this=0x7f1f258cdde0, aCreatePluginList=1, 
    aPluginsChanged=0x7fff3ef1a88c) at nsPluginHostImpl.cpp:5376
#11 0x00007f1f34d47a26 in nsPluginHostImpl::LoadPlugins (this=0x2) at nsPluginHostImpl.cpp:5304
#12 0x00007f1f34d3c052 in nsPluginHostImpl::FindPluginForType (this=0x2, 
    aMimeType=0x7f1f23bf3b00 "** Message: GetValue variable 2 (2)\n", aCheckEnabled=36) at nsPluginHostImpl.cpp:4495
#13 0x00007f1f34d3cc11 in nsPluginHostImpl::IsPluginEnabledForType (this=0x2, 
    aMimeType=0x7f1f23bf3b00 "** Message: GetValue variable 2 (2)\n") at nsPluginHostImpl.cpp:4213
#14 0x00007f1f34e13c5d in nsJVMManager (this=0x7f1f23a19190, outer=0x7f1f23a191c0) at nsJVMManager.cpp:395
#15 0x00007f1f34e18e2a in nsJVMManagerConstructor (aOuter=0x0, aIID=@0x7f1f24bc4c70, aResult=0x7fff3ef1a9f0)
    at nsCJVMManagerFactory.cpp:57
#16 0x00007f1f34ea41f6 in nsComponentManagerImpl::CreateInstance (this=<value optimized out>, 
    aClass=<value optimized out>, aDelegate=0x0, aIID=@0x7f1f24bc4c70, aResult=0x7fff3ef1a9f0)
    at nsComponentManager.cpp:1670
#17 0x00007f1f34ea3aed in nsComponentManagerImpl::GetService (this=0x7f1f28212170, aClass=@0x7f1f24bc4cc0, 
    aIID=@0x7f1f24bc4c70, result=0x7f1f258cdea0) at nsComponentManager.cpp:1882
#18 0x00007f1f24ba7eae in CPluginServiceProvider::QueryService ()
   from /usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#19 0x00007f1f24bab213 in JavaPluginFactory5::Initialize ()
   from /usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#20 0x00007f1f24baa823 in JavaPluginFactory5::Create ()
   from /usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#21 0x00007f1f24ba7842 in NSGetFactory () from /usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#22 0x00007f1f34d4e5a0 in nsPluginFile::GetPluginInfo (this=0x7fff3ef1aef0, info=@0x7fff3ef1ad20)
    at nsPluginsDirUnix.cpp:453
#23 0x00007f1f34d474b5 in nsPluginHostImpl::ScanPluginsDirectory (this=0x7f1f258cdde0, 
    pluginsDir=<value optimized out>, compManager=<value optimized out>, aCreatePluginList=1, 
    aPluginsChanged=0x7fff3ef1b034, checkForUnwantedPlugins=0) at nsPluginHostImpl.cpp:5181
#24 0x00007f1f34d4773f in nsPluginHostImpl::ScanPluginsDirectoryList (this=0x7f1f258cdde0, dirEnum=0x7f1f23bfac70, 
    compManager=0x7f1f28212170, aCreatePluginList=1, aPluginsChanged=0x7fff3ef1b0e8, checkForUnwantedPlugins=0)
    at nsPluginHostImpl.cpp:5284

(I don't think the strange values in some arguments have anything to do with it)

The fix for bug 419582 introduced this infinite loop by having the plugin host being queried to know whether the java plugin is enabled or not. The problem here is that a plugin, itself, is instanciating the JVMManager while plugin initialization is running.

Having nsPluginHostImpl::IsPluginEnabledForType return an error when mPluginsLoaded is false would cut the infinite loop, but i'm not sure the plugin will ever get any useful, then...

Any ideas ?

Comment 1

[Mike Hommey [:glandium]]

(In reply to comment #0)
> Having nsPluginHostImpl::IsPluginEnabledForType return an error when
> mPluginsLoaded is false would cut the infinite loop, but i'm not sure the
> plugin will ever get any useful, then...

Confirmed, the plugin is not used, then.

Mike

Comment 2

[Mike Hommey [:glandium]]

Attachment: patch?

As amazing as it can look, this patch seems to work.

Comment 3

[Mike Hommey [:glandium]]

On the other hand, once you are past this bug, you hit another problem:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402165

And once you get past that one, you get a random crash in
#6  0x00007fe5d812b234 in JavaPluginFactory5::Initialize () from /usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#7  0x00007fe5d812a823 in JavaPluginFactory5::Create () from /usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so
#8  0x00007fe5d8127842 in NSGetFactory () from /usr/lib/j2se/1.4/jre/plugin/amd64/mozilla/libjavaplugin_oji.so

I'm not sure this java plugin is worth the trouble of trying to fix the present bug, as it seems to be the only one triggering the infinite loop...

Comment 4

[timeless]

are you forging your user agent?

Comment 5

[Mike Hommey [:glandium]]

No (except for the fact that Iceweasel is not Firefox), and I could reproduce the crash with firefox from Ubuntu (after I forced j2re1.4 to be installed despite the conflict)

Comment 6

[Johnny Stenback (:jst)]

nsPluginHostImpl is a singleton service, could we simply add a bit to it so it know whether it's scanning the directories and never re-enter? I haven't spent much time thinking about this, so I'm mostly just thinking out loud here. As for fixing bugs for Java 1.4, that version is way old and probably has other scary bugs, which should be reason enough to upgrade etc...

Comment 7

[Johnny Stenback (:jst)]

Marking INVALID as the code touched here no longer exists.