United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7014761 pogo games crashes AOL browser with 6u23
JDK-7014761 : pogo games crashes AOL browser with 6u23

Details
Type:
Bug
Submit Date:
2011-01-26
Status:
Closed
Updated Date:
2011-05-02
Project Name:
JDK
Resolved Date:
2011-02-16
Component:
deploy
OS:
windows_xp
Sub-Component:
plugin
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u23
Fixed Versions:
6u24 (b06)

Related Reports
Relates:
Relates:

Sub Tasks

Description
There has been a high volume of incidents through "Incident Manager" as well comments in "OpinionLab" where consumers complained that many Pogo games are no longer working since they updated to Java version 6u23,  but when the uninstalled 6u23 and reinstalled either 6u22 or 6u21 and they were able to play the Pogo games again, therefore it is a regression.
One consumer had been in contact with Electronic Arts (EA) support team, and was advised to uninstall 6u23 and directed them to download 6u22, which also shows the scope of this problem.
Here are some of the important details I have gathered from the various reports in the "Incident Manager":

* Operating System: Windows XP, sp2 and 3, as well some reported Windows 2000 so far the only 2 operating systems were reported with this issue.

* Browsers: IE 7 and 8, Latest version of Firefox and AOL desktop 9.6

* It affects many games, such as: First Class Solitaire, Scrabble, Spades, Word Whomp, Qwerty, Lottso, Dominos, High Stakes Pool, Jungle Gin, Payday, Free Cell, Canasta, Battleship, Keno, Bingo Lau and Clue.

* Reported error messages "Application Runtime Error" or "Microsoft visual c ++ runtime library - Runtime Error".

                                    

Comments
SUGGESTED FIX

webrev: http://javaweb.sfbay.sun.com/~ngthomas/pogo/webrev/
                                     
2011-01-31
EVALUATION

The crash only reproduces with AOL browser which comes with AOL Desktop.
I was able to reproduce the problem with AOL Desktop 9.6 on XP sp3.

Attached is a windbg log. The problem seems to be in the ShowDocument.

Also attaching a hs err log for the client vm.
                                     
2011-01-29
EVALUATION

This problem was introduced in 6u23 b02 via the fix for 6946479.

The problem is due to we're typecasting a IDispatchPtr to a IWebBrowser2 ptr.

A possible fix is to use QueryInterface to obtain the IWebBrowser2 ptr from the IDispatchPtr.
                                     
2011-01-31
EVALUATION

when running in AOL, IWebBrowser2->get_HWND() will return EFAIL.   So basically when running in AOL, RetrieveNewWindowHWND will return NULL, and our showDocument tricks won't be used at all.

There is this:   http://codecentrix.blogspot.com/2007/11/when-iwebbrowser2gethwnd-returns-efail.html

I tried to apply it, but it is still EFAIL.

So basically we have fix for crash on AOL.  But showDocument on AOL might still have problem.  (Although I don't see any problem while playing pogo games - but more testing on showDocument on AOL is needed)
                                     
2011-01-31
EVALUATION

It seems that we do not care about C++ [com_error] exception support.

Please, remember that each COM call has HRESULT as return value (there is an exception for local interfaces, but you never face it in external API). If you found a wrapper that returns parameter directly, be ready to surprise. In the most of cases the surprise is a potential C++ exception, and in major of cases it is  [com_error].

I would like to be sure about common understanding of
#import <shdocvw.dll>
magic and related cases. Each COM API DLL with Dispatch interfaces for scripting languages contains the binary resource in special format. That is TypeInfo structures with IDL descriptors. Those descriptors could be read from DLL by MS tool OleView in human-readable form.

"C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\bin\OleView.Exe" as an example.

Basing on IDL information for interfaces from imported DLLs, stuff structures and COM wrappers are generated by pre-compiler.
For mention case in my build system generated files are:
C:\Projects\deploy\build\tmp\jpishare\obj\shdocvw.tlh (headers)
C:\Projects\deploy\build\tmp\jpishare\obj\shdocvw.tli  (implementations)
That files are included in place of [#import <shdocvw.dll>] directive. 

The CR problem is initiated by emitted and uncatched C++ exception [com_error]
Look at  %root%\build\tmp\jpishare\obj\shdocvw.tli.
Here we see
inline long IWebBrowserApp::GetHWND ( ) {
    long _result = 0;
    HRESULT _hr = get_HWND(&_result);
    if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
    return _result;
} 
Seems we have partially implemented IWebBrowserApp interface and we are not ready to any HRESULT that is different from S_OK.
                                     
2011-01-31
SUGGESTED FIX

http://jdksrc.us.oracle.com/hg/6u24/Sustaining/deploy/rev/4c10ed98dce7
                                     
2011-01-31
SUGGESTED FIX

also need this change, otherwise won't build on 64-bit windows.

http://jdksrc.sfbay.sun.com/hg/6u24/Sustaining/deploy/rev/3c2cce70d1df
                                     
2011-02-01



Hardware and Software, Engineered to Work Together