Name: clC74495 Date: 09/13/99


In awt_Graphics.cpp, there is a method called ResetDC, which as the comment says is a "Workaround for NT 4.0 bug, where the DC in a window from a CS_OWNDC class becomes invalidated inexplicibly." For some unknown reason, the DC of a window can randomly become invalid. The AWT code attempts to work around this bug by calling ResetDC whenever the DC is determined to be invalid.
It seems like this workaround is the only possible solution. But it means that you have to catch all the places where the DC can become invalid and call ResetDC there. We've found a few that were missed. One instance in particular can cause a crash. This is in the function LogicalSelectClipRgn() in awt_Graphics.cpp. If the DC is invalid when this function is called, the call to GetWindowExtEx() will give garbage values for wExt. These values are then used as the denominator in a computation, so if the garbage values are zero then you will get a divide by zero error. The simple solution to prevent the crash is to check the return value of GetWindowExtEx(). Currently this return value is ignored. So you might change it to look like this:
if ((::GetWindowExtEx(hDC, &wExt) == ERROR) ||
    (wExt.cx == 0) || (wExt.cy == 0)) {
    return ERROR;
}
The caller of LogicalSelectClipRgn() should then check for an ERROR return value and call ResetDC if an error occured (the call to ResetDC cannot be made inside LogicalSelectClipRgn because it does not have handle to the AwtSharedDC object).
There are two additional places where we have found the DC can become invalid, and thus where ResetDC should be called. These are:
1) In AwtGraphics::ValidateDC(), where SelectObject() is called to select the m_pFont into the DC.
2) In AwtGraphics::SetFont(), where SelectObject() is called to select pFont into the DC.
In both of these cases, the return value of SelectObject() should be checked, and if it is ERROR, call ResetDC() and try the SelectObject() call again.
Note that I cannot give you a test case where this will reliably occur. It occurs randomly as we run our applications. However, since JavaSoft has obviously seen this problem before, this is really just a request for an extension to the existing solution. Additionaly, the code is no-risk, since it only gets executed in an error situation. We made the changes described above locally and it solved the problem.
(Review ID: 94976)
======================================================================