GPF on closing Scintilla

About 5% of the time I close a window with a Scintilla view on it I get a
GPF. I've added an override (stack frame 17 below)
toMultilineTextEdit>>wmPaint:wParam:lParam: as follows:
     handle isNil ifTrue: [^1].
     ^super
      wmPaint: message
      wParam: wParam
      lParam: lParam.

The handle is not nil when the method is entered, but it is nil by the time
the walkback opens. The handle is valid up to frame 19, but not after that.
I assume that there is some race condition where the close event is being
ptocessed before this message finishes.

Has anyone else seen something like this? Any suggestions?

James Foster


STACK:

25:    ProcessorScheduler>>gpFault:
24:    [] in ProcessorScheduler>>vmi:list:no:with:
23:    BlockClosure>>ifCurtailed:
22:    ProcessorScheduler>>vmi:list:no:with:
21:    UserLibrary(ExternalLibrary)>>invalidCall
20:    UserLibrary>>callWindowProc:hWnd:msg:wParam:lParam:
19:    ScintillaView(ControlView)>>defaultWindowProcessing:wParam:lParam:
18:    ScintillaView(ControlView)>>wmPaint:wParam:lParam:
17:    ScintillaView(MultilineTextEdit)>>wmPaint:wParam:lParam:
16:    ScintillaView(View)>>dispatchMessage:wParam:lParam:
15:    [] in InputState>>wndProc:message:wParam:lParam:cookie:
14:    BlockClosure>>ifCurtailed:
13:    ProcessorScheduler>>callback:evaluate:
12:    InputState>>wndProc:message:wParam:lParam:cookie:
11:    InputState>>pumpMessage:
10:    InputState>>loopWhile:
9:    InputState>>mainLoop
8:    [] in InputState>>forkMain
7:    ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
6:    [] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
5:    BlockClosure>>ifCurtailed:
4:    BlockClosure>>ensure:
3:    ExceptionHandler(ExceptionHandlerAbstract)>>try:
2:    BlockClosure>>on:do:
1:    [] in BlockClosure>>newProcess

Hi James,

> Has anyone else seen something like this?

Yes, I am seeing the same thing fairly regularly. I think this is an
open issue in Object Art's bug tracker system from the beta.

> I assume that there is some race condition

Yes, I would be fairly sure that the race condition is between the new
process (new main) forked before opening the "Save Changes" MessageBox,
 and the old main process.

FWIW: I have been bitten by this more than once in my own applications.
As a general rule, after showing a MessageBox, I use #postToInputQueue
to perform any subsequent actions ... especially closing views etc. For
this reason, I tend to avoid using Dolphin's standard #onCloseRequested
pattern when I need to show a MessageBox.

Steve
--
Steve Waring