SmallInteger>>size stripped

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

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]

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]