JDK-7014761 : pogo games crashes AOL browser with 6u23
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u23
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2011-01-26
  • Updated: 2014-10-24
  • Resolved: 2011-02-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u24 b06Fixed
Related Reports
Relates :  
JDK-7042863 - java crashes on pogo
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 also need this change, otherwise won't build on 64-bit windows. http://jdksrc.sfbay.sun.com/hg/6u24/Sustaining/deploy/rev/3c2cce70d1df
01-02-2011
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.
31-01-2011
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)
31-01-2011
SUGGESTED FIX webrev: http://javaweb.sfbay.sun.com/~ngthomas/pogo/webrev/
31-01-2011
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.
31-01-2011
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.
29-01-2011