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.
See CR # 6277082
###@###.### 2005-06-14 05:53:50 GMT
Comments
EVALUATION
With 1.4.2_XX, the crash happens when an applet is reloaded very fast. At this time, the applet's init is running on a different thread, which requests the webpage document.URL via JavaScript in AppletViewer.getDocumentBase(). This fires a WM_JSOBJECT_INVOKEMETHOD message using ::PostMessage() and does a WaitAndProcessJsToJava() on 2 handles. During the crash, the hInstanceEvent [WAIT_OBJECT_0=1] is getting signaled. Hence the wait comes out faster and the required data structure (INVOLESTRUCT) is freed. This freed memory is getting accessed in the event handler for message WM_JSOBJECT_INVOKEMETHOD - which is CAxControl::OnJSInvokeMethod() and the ACCESS VIOLATION happens.
The WM_JSOBJECT_INVOKEMETHOD message is handled in the stack of IExplorerEmbeddedFrame.destroy() call during the wait (WPlatformService.waitEvent()) after posting the WINDOW_CLOSING event. In this call stack, CAxControl::Cleanup() signals the hInstanceEvent before invoking the IEEFrame.destroy() method.
When the CAxControl::OnJSInvokeMethod(LPARAM==INVOKESTRUCT) is getting executed, the Initer thread had been already signaled and cleans up the INVOKESTRUCT data.
###@###.### 2005-06-14 05:53:50 GMT