483237 - Loading Java applets either hangs or crashes the browser

Status: RESOLVED DUPLICATE of bug 484744

(Core Graveyard :: Plug-ins, defect)

Description

[Allan]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1b3pre) Gecko/20090130 SeaMonkey/2.0a3pre
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1b3pre) Gecko/20090130 SeaMonkey/2.0a3pre

Going to above example URL will either hang the browser using 100% CPU or crash. This regression start with OS/2 version build 20090130, while version build 20090124 works fine.

Here are a few entries from POPUPLOG.OS2:
------------------------------------------------------------

03-13-2009  16:51:58  SYS3170  PID 00b6  TID 0001  Slot 00ba
Y:\SEAMONKEY.EXE
00000022
203de880
P1=00000022  P2=00000020  P3=00000020  P4=20fa4340  
EAX=0011c2c4  EBX=00000023  ECX=00000020  EDX=00000000
ESI=0000150b  EDI=00000000  
DS=0053  DSACC=d0f3  DSLIM=3fffffff  
ES=0053  ESACC=d0f3  ESLIM=3fffffff  
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:15945750  CSACC=d0df  CSLIM=3fffffff
SS:ESP=0053:0011d8f8  SSACC=d0f3  SSLIM=3fffffff
EBP=0011d98c  FLG=00210217

LIBC063.DLL

------------------------------------------------------------

03-13-2009  16:58:03  SYS3170  PID 00bc  TID 0001  Slot 00ac
Y:\SEAMONKEY.EXE
00000000
0011cc40
EAX=0011c438  EBX=0000041e  ECX=8be58955  EDX=00000000
ESI=0000150b  EDI=00000000  
DS=0053  DSACC=d0f3  DSLIM=3fffffff  
ES=0053  ESACC=d0f3  ESLIM=3fffffff  
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:15e25750  CSACC=d0df  CSLIM=3fffffff
SS:ESP=0053:0011d90c  SSACC=d0f3  SSLIM=3fffffff
EBP=0011d9a0  FLG=00210297

SEAMONKEY.EXE 0002:000fcc40

------------------------------------------------------------

03-13-2009  16:58:49  SYS3170  PID 00be  TID 0001  Slot 00ac
Y:\SEAMONKEY.EXE
00000022
20ac17c0
P1=00000022  P2=00000020  P3=00000020  P4=20b4c000  
EAX=0011c9fc  EBX=00000023  ECX=00000020  EDX=00000000
ESI=0000150b  EDI=00000000  
DS=0053  DSACC=d0f3  DSLIM=3fffffff  
ES=0053  ESACC=d0f3  ESLIM=3fffffff  
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:15e25750  CSACC=d0df  CSLIM=3fffffff
SS:ESP=0053:0011e030  SSACC=d0f3  SSLIM=3fffffff
EBP=0011e0c4  FLG=00210217

LIBC063.DLL

This bug could be related to Linux bug 479254


Reproducible: Always

Steps to Reproduce:
Gtot URL, and prepare to die :-)

Comment 1

[Walter Meinl]

Last lines from the log of a debug firefox-3.2a1pre build of today:
ipluginw: nsresult downQueryInterface(void*, const nsIID&, void**): enter this=0x22ee3e80 (down)
ipluginw: nsresult downQueryInterface(void*, const nsIID&, void**): aIID={e7d48c00,e1f1,11d2,83,60,fb,c8,ab,c4,ae,7c} <unknown> (0x211d7588)
ipluginw: nsresult downQueryInterface(void*, const nsIID&, void**): Unsupported interface!!!
ipluginw.dll tries to create a wrapper for an interface with a UUID starting with e7d48c00, this has been the UUID of nsIPluginInstancePeer2.{idl,h}. The UUID was changed in bug474866 http://hg.mozilla.org/mozilla-central/rev/0932e7c4d976
to 79a2d210 ... This is also the UUID listed in xpti.dat of the debug build.
So, the question is how the old UUID is picked up by ipluginw.dll.
When I manually change back the old UUID into nsIPluginInstancePeer2.idl and recompile the modules/plugin directory I can load the testcase without crashing.

Comment 2

[Peter Weilbacher]

I guess you tried to search the whole bin directory for "e7d48c00"? Otherwise I have no idea, how that could happen. You did a full rebuild, right?

Comment 3

[Walter Meinl]

(In reply to comment #2)
> I guess you tried to search the whole bin directory for "e7d48c00"? Otherwise I
> have no idea, how that could happen. You did a full rebuild, right?
It was a full rebuild, and to test whether all was ok I did it twice, waiting a few days in between. When you grep in the directories of Seamonkey 20090130 and 20090124, you'll find matches for ipluginw.dll and xpti.dat for 79a2d210 and e7d48c00, respectively. Could the old UUID be hardcoded by the downstream npj2.dll and friends?

Just to mention this, when I open the java tester site (javatester.org)  with that debug build java starts fine, but from the log I can see that it doesn't need nsIPluginInstancePeer2 in that case.

Comment 4

[Walter Meinl]

I reverted the UUID for nsIPluginInstancePeer2.idl to the old e7d48c00... values and rebuilt the whole tree this time w/o debug. Again, using the old UUID let the test address as well as the site Allan posted in the news group https://www.lsb.dk/bank/lsb/internetbank/ successfully load. Thus, it appears that the crash is indeed a consequence of the change in the UUID of nsIPluginInstancePeer2.idl.

Comment 5

[Peter Weilbacher]

I haven't looked but could the UUID be hardcoded in the plugin?

Comment 6

[Allan]

I can find 'e7d48c00' in npj2.dll and in jpins6.dll and jpins7.dll
The last 2 are some original windows dlls in the Java kit.

Comment 7

[Walter Meinl]

(In reply to comment #6)
> I can find 'e7d48c00' in npj2.dll and in jpins6.dll and jpins7.dll
> The last 2 are some original windows dlls in the Java kit.

With which program did you find that? grep doesn't show a hit when I search through my plugins directory.

(In reply to comment #5)
> I haven't looked but could the UUID be hardcoded in the plugin?
Same idea that I had in comment #4, but how do we find it out w/o sources? The UUIDs for flash5 and 7 are hard coded in modules/plugin/os2wrapper/wrap_XPCOM_3rdparty.h. Maybe we could redefine the UUID for nsIPluginInstancePeer2.idl there. That would at least not disturb other platforms, though it's very ugly. However, which better choices do we have?

Comment 8

[Walter Meinl]

Attachment: hack to locally revert the uuid of nsIPluginInstancePeer2.idl for ipluginw.dll

hack attack!

Comment 9

[timeless]

Comment on attachment 369389 [details] [diff] [review]
hack to locally revert the uuid of nsIPluginInstancePeer2.idl for ipluginw.dll

there are other ways to do this (you could make a wrapper object).

In this case, you should at least provide a test to ensure that the ID is exactly what you're expecting and add a note that the reason this is ok is that the new interface only differs by the presence of an additional vtable method, which callers w/ the older iid will not try to use because it wasn't present in the version you're promising.

Comment 10

[Allan]

(In reply to comment #7)

> (In reply to comment #6)
> > I can find 'e7d48c00' in npj2.dll and in jpins6.dll and jpins7.dll
> > The last 2 are some original windows dlls in the Java kit.
> 
> With which program did you find that? grep doesn't show a hit when I search
> through my plugins directory.

Search for the opposite byte order: '008cd4e7'

Comment 11

[Peter Weilbacher]

(In reply to comment #10)
> Search for the opposite byte order: '008cd4e7'

Better uncompress the file in question and then use strings and grep:

   $ copy npj2.dll npj2uncompress.dll
   $ lxlite /X npj2uncompress.dll
   $ strings npj2uncompress.dll | grep e7d48c00
   e7d48c00-e1f1-11d2-8360-fbc8abc4ae7c

If you grep for grep "\-....\-....\-" you can see that it contains a frightening number of hard-coded UUIDs. Luckily the ones that I checked are indeed FROZEN.

As an alternative to the patch here we could just patch the Java binaries.

Comment 12

[Walter Meinl]

(In reply to comment #11)
Cool!

> As an alternative to the patch here we could just patch the Java binaries.
Do you mean it is possible to create such a binary patch that would allow the plugin to work with both iids? Because the 3.0.x series will still need the old iid.

Comment 13

[Peter Weilbacher]

No, at least I don't have any knowledge how that could be achieved. I was just suggesting to replace the old IID with he new one. (Should be very simple: uncompress as above, use a hex editor to replace the IID, and re-compress.)
But yes, I see your point, this would be less desirable.

Perhaps we can at least partly follow timeless' suggestion and set the old IID in wrap_XPCOM_3rdparty.h in addition to the new one (using another macro). Then in  where kPluginInstancePeer2IID is used we can query for both kPluginInstancePeer2IID and kPluginInstancePeer2IID_Old. Let me give this a try one of these days.

Comment 14

[Peter Weilbacher]

Comment on attachment 369389 [details] [diff] [review]
hack to locally revert the uuid of nsIPluginInstancePeer2.idl for ipluginw.dll

I decided that for the moment I don't like this approach.

Comment 15

[Walter Meinl]

I think there is a solution coming in 3.5.1, see bug484744, tier_1 platforms have problems, too, with the UID change of nsIPluginInstancePeer2.