112467 - Segfault if non-plugin shared library exists in plugin directory

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[tenthumbs]

If a non-plugin shared library winds up in the plugin directory for some
reason then mozilla will crash as soon as it rescans the plugin
directory. Any shared library seems to cause a crash.

I stumbled into this when I was re-compiling an old plugin but I omitted 
an object file from the link. This meant a few symbols were missing 
which strongly suggests that mozilla doesn't always check that a symbol 
is not null. Since it looks like mozilla's plugin code treats any 
library that doesn't meet certain standards as a 4.x plugin this would 
also explain why any library causes a crash.

I haven't looked all that carefully at the code but I did find this in 
ns4xPlugin::CreatePlugin (XP_UNIX)
 NP_PLUGINSHUTDOWN pfnShutdown = 
  (NP_PLUGINSHUTDOWN)PR_FindSymbol(aLibrary, "NP_Shutdown");
but I can't find any place where mozilla checks if the symbol is null. 
There may well be other places.

However, it not this simple. The above behavior occurs if you add a 
library after mozilla has run at least once. If you wipe the 
installation, unpack a new tarball, and add a library before running 
mozilla for the first time then mozilla will not crash and about:plugins 
will have an entry for the non-plugin library but it will have garbage 
characters for its description. Mozilla will work until you touch the 
library. Mozilla will then always crash as before.

This last part may be another problem. The issue here is that mozilla 
should never crash just because a library isn't a plugin.

Comment 1

[av (gone)]

Reassigning to serge.

Comment 2

[Sergey Lunegov]

Attachment: Patch

The proposed patch fixes problem with non-plugin shared library

Comment 3

[Sergey Lunegov]

I created Attachment #62083 [details] [diff] which fixes problem with non-plugin
shared library. I couldn't reproduce crashing when plugin is updated/touched
during browser running. Reporter, would you please describe how should
I act to reproduce crashing by updating/tocuhing plugin shared libraries.

Comment 4

[tenthumbs]

about:plugins then press reload.

Comment 5

[Sergey Lunegov]

I couldn't reproduce crashing by following your last comment:
'about:plugins then press reload'. Would you please test it once again.
I tested it with CVS build from 12142001 on Linux Redhat 7.1.
I couldn't reproduce it (crashing by updating/touching) with and without my
 patch.

Comment 6

[tenthumbs]

I tstill crashed with a 12-18-08 nightly which is the last one I've had 
time to test.

Here's what I did:
  cp /dev/null empty.c
  gcc -shared -o empty.so -fPIC empty.c
  cp  empty.so /path/to/mozilla/plugins/empty.sp (note the name change)
  mozilla about:plugins
  mv /path/to/mozilla/plugins/empty.sp /path/to/mozilla/plugins/empty.so
  press reload in mozilla window

Comment 7

[serge (gone)]

This bug has been fixed by check in for bug 115308,
see comment #16 for explanation of the possible crash.
About Sergey Lunegov patch I would like to say that 
unfortunately I have not found the exact requirements on implementation of 
NPP_Shutdown in plugin's spec 
http://developer.netscape.com/docs/manuals/communicator/plugin/pgfns.htm#1006913
So it's perfectly legal for plugins do not have that function at all, and in our 
current code we do handle it properly
    604 ns4xPlugin::Shutdown(void)
    605 {
    606   NPP_PLUGIN_LOG(PLUGIN_LOG_BASIC, ("NPP Shutdown to be called: 
this=%p\n",this));
    607
    608   if (nsnull != fShutdownEntry) {
    609 #ifdef XP_MAC
    610     CallNPP_ShutdownProc(fShutdownEntry);
    611     ::CloseResFile(fPluginRefNum);
    612 #else
    613     NS_TRY_SAFE_CALL_VOID(fShutdownEntry(), fLibrary);
    614 #endif
    615
    616     fShutdownEntry = nsnull;
    617   }

Comment 8

[shrirang khanzode]

v