Blair,
The callstack below had me confused (maybe it still does<g>). It appears to indicate that one of my creations got into trouble sending #size to a SmallInteger. Hopefully, the problem is simply an incorrect model type, which is very plausible given the various ways the presenter in question is used. I was initially concerned because SmalltInteger>>size sends #shouldNotImplement, but it is stripped in the offending exe. A quick test of the primitive with a SmallInteger receiver gives the same result: a reading GPF. Is SmalltInteger>>size cosmetic, or is the GPF potentially dangerous? The error below happened about 45 minutes before a lockup of the exe. The user reports doing something that would have gone through the same code (with different receivers though), after which the exe was unresponsive, displaying a wait cursor. Background threads were running, and UI updates were happening, though perhaps a little sluggishly. At one point, I switched to another app. I could only get back to the "locked" exe by the task bar. I tried control-break, which I have rigged to do a dump of all threads; it failed to write a log, which either means that it couldn't write/flush the file, or simply that there was nothing to interrupt. In the interest of full disclosure, I'm using Steve's ViewQueue to avoid problems with deferred actions when menus are popped and left open (you'd be amazed how often my users do that). As an aside, it occurs to me that I probably do not need it in the code in question, because if the dialog is opening, then a menu isn't going to be open. In summary, I suspect that somewhere in or before the Dialog's #onViewOpened, I errantly set a SmallInteger as the model of a text presenter, causing #size to be sent to a SmallInteger, causing a GPF (because of the stripped method), which then left the exe in a modal loop that would have been ended by the dialog that never opened. Does that seem reasonable? The part I don't understand is why it's so rare. Have a good one, Bill : Unhandled exception in EarClientSession - a GPFault('Invalid access to memory location. Reading 0x55, IP 0x419D6A (C:\Program Files\EAR\UF-ElectronicAnesthesiaRecord.exe)'): 'Invalid access to memory location. Reading 0x55, IP 0x419D6A (C:\Program Files\EAR\UF-ElectronicAnesthesiaRecord.exe)' ProcessorScheduler>>gpFault: [] in ProcessorScheduler>>vmi:list:no:with: BlockClosure>>ifCurtailed: ProcessorScheduler>>vmi:list:no:with: SmallInteger(Object)>>primitiveFailed SmallInteger(Object)>>size [] in KeyboardValuePresenterText(KeyboardValuePresenterAbstract)>>onViewOpened SWViewActionQueue>>dispatchUser:wParam:lParam: SWViewActionQueue(View)>>dispatchMessage:wParam:lParam: [] in InputState>>wndProc:message:wParam:lParam:cookie: BlockClosure>>ifCurtailed: ProcessorScheduler>>callback:evaluate: InputState>>wndProc:message:wParam:lParam:cookie: InputState>>pumpMessage: InputState>>loopWhile: InputState>>mainLoop [] in InputState>>forkMain ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry [] in ExceptionHandler(ExceptionHandlerAbstract)>>try: BlockClosure>>ifCurtailed: BlockClosure>>ensure: ExceptionHandler(ExceptionHandlerAbstract)>>try: BlockClosure>>on:do: [] in BlockClosure>>newProcess -- Wilhelm K. Schwab, Ph.D. [hidden email] |
"Bill Schwab" <[hidden email]> wrote in message
news:bp167t$1j3flm$[hidden email]... > Blair, > > The callstack below had me confused (maybe it still does<g>). It appears to > indicate that one of my creations got into trouble sending #size to a > SmallInteger. Hopefully, the problem is simply an incorrect model type, > which is very plausible given the various ways the presenter in question is > used. I was initially concerned because SmalltInteger>>size sends > #shouldNotImplement, but it is stripped in the offending exe. > > A quick test of the primitive with a SmallInteger receiver gives the same > result: a reading GPF. Is SmalltInteger>>size cosmetic, or is the GPF > potentially dangerous? >... It is a logical error to send #size to SmallInteger. The development time #shouldNotImplement traps this error, and is useful for testing etc. Assuming complete test coverage one wouldn't expect to hit any #shouldNotImplement errors, so the image stripper offers the option of removing these methods (which is the default). If you want to keep this protection at runtime, then just turn off the image stripper option to remove #shouldNotImplement methods. In this particular case the primitive implementation of #size in Object is not expecting the receiver of the message to be immediate, and so it GPFs when trying to treat the SmallInteger receiver as an object pointer. However this is a "read" GPF, and therefore benign. In fact you could regard it as a rather stronger form of #shouldNotImplement :-). Regards Blair |
Blair,
> It is a logical error to send #size to SmallInteger. Incidentally, *why* is it a logic error -- it would seem more reasonable (to me) to answer 0. After all LargeInteger responds to #size, and I don't think that the difference between LargeInteger and SmallInteger is supposed to be very "visible" to the programmer. -- chris |
In reply to this post by Blair McGlashan
Blair,
> It is a logical error to send #size to SmallInteger. No argument there. > The development time > #shouldNotImplement traps this error, and is useful for testing etc. > Assuming complete test coverage one wouldn't expect to hit any > #shouldNotImplement errors, That's a nice assumption, but probably not very practical given that the users outnumber me, work around the clock, and can be very creative, not to mention that error conditions can cause unexepected inputs. It gets even more fun because the users are working on 500MHz Celerons, so their machines are always more stressed than mine, which is easy to forget. > so the image stripper offers the option of > removing these methods (which is the default). If you want to keep this > protection at runtime, then just turn off the image stripper option to > remove #shouldNotImplement methods. > > In this particular case the primitive implementation of #size in Object is > not expecting the receiver of the message to be immediate, and so it GPFs > when trying to treat the SmallInteger receiver as an object pointer. However > this is a "read" GPF, and therefore benign. In fact you could regard it as a > rather stronger form of #shouldNotImplement :-). Since the override is purely cosmetic, then I can forget about collateral damage to the image and focus on how an incorrect model was assigned. Actually, I can explain it; I'm less confident that I can prove it. Thanks! Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
In reply to this post by Chris Uppal-3
Chris,
> > It is a logical error to send #size to SmallInteger. > > Incidentally, *why* is it a logic error -- it would seem more reasonable (to > me) to answer 0. > > After all LargeInteger responds to #size, and I don't think that the difference > between LargeInteger and SmallInteger is supposed to be very "visible" to the > programmer. Interesting point. However, my current puzzle would be just as troublesome had the value been a LargeInteger - it should have been a String by the time the code reached the offending line. I suspect the problem is one of timing with deferred actions. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Free forum by Nabble | Edit this page |