<rdar://problem/5614257> Crash in timer / hashtable code due to uncaught...
authorsfalken@apple.com <sfalken@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 6 Dec 2007 23:31:46 +0000 (23:31 +0000)
committersfalken@apple.com <sfalken@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 6 Dec 2007 23:31:46 +0000 (23:31 +0000)
commit6e9fd64d5d5d3f518e542615f0e62440fa9a208d
tree7b98fb5a1c41a41ceef95b53d453285e6a271cef
parent68ac7f4b5c4a23bfb1a11a6f43ef30f9bb2f8423
    <rdar://problem/5614257> Crash in timer / hashtable code due to uncaught exception

        Don't use callback-based timers, since these cause Windows to eat Windows crashes
        in code the timers call.

        Windows appears to be defending against "shatter" attacks partially by setting
        up a structured exception block while dispatching callback-based WM_TIMERs.

        I verified this by adding a divide by zero into some timer callback code.
        In the case where the timer was dispatched via a callback, the divide by zero
        exception was silently handled and ignored, with execution continuing after
        our call to DispatchMessage.  When processed via the WNDPROC, no SEH
        block was established by Windows, and our divide by zero generated a real
        crash (which is what we wanted).

        Windows handling our crashes for us led us to leave the timer data structures
        in an invalid state so the next time a timer was set, we'd crash accessing an
        invalid HashMap of timer data.

        Reviewed by Hyatt.

        * platform/win/SharedTimerWin.cpp:
        (WebCore::TimerWindowWndProc):
        (WebCore::setSharedTimerFireTime):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@28500 268f45cc-cd09-0410-ab3c-d52691b4dbfc
WebCore/ChangeLog
WebCore/platform/win/SharedTimerWin.cpp