Access is denied. (OS error 16r5)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Access is denied. (OS error 16r5)

Kjell Harald Ulstad
Hi folks.

Occasionally, we encounter the following error: Runtime error: Access is
denied. (OS error 16r5).
The error pop up when a Screensaver is running.
Probably because VSE tries to write to the screen and Microsoft have
changed the return value when a Screensaver is running  ;-)
The error log tells us that this has to do with GraphicsTool>>line:
(and other places...)
I've come up with a proposal for a solution (shown below the error log)
but is it a better way to solve it?

Error log:

Runtime error: Access is denied. (OS error 16r5)

Error(Exception)>>defaultAction
Error(Exception)>>activateHandler: <anUndefinedObject>
Error(Exception)>>handle
Error(Exception)>>signal
Error class(Exception class)>>signal: <'Access is denied. (O...'>
Pen(Object)>>osError: <5>
Pen(Object)>>osError
[] in GraphicsTool>>line:
Array(IndexedCollection)>>do: <aBlockClosure>
Pen(GraphicsTool)>>line: <aPoint>
Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint>
Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in>
CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle>
CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle>
clipRect: <aRectangle>
[] in CPSubPane>>display
CX3DTextFrame(Window)>>doGraphics: <aBlockClosure>
CX3DTextFrame(CPSubPane)>>display
CX3DTextFrame(Window)>>display: <aRectangle>
CX3DTextFrame(Window)>>wmPaint: <0> with: <0>
NotificationManager>>notify: <aWinMessage>
NotificationManager>>notifyRecursive
NotificationManager>>recursiveMessage
SystemDictionary>>recursiveMessage
SystemDictionary>>launch
NotificationManager>>readWinQueue
NotificationManager>>runEventLoop
Message>>perform
Message>>evaluate
Process>>safelyEvaluate: <aMessage>

The cause seems to be '^self osError' and below is a proposal for a
solution:

line: aPoint
                "Private - Draw a line from the current location
        to aPoint.  Answer the new location."

                | anError |
                self allHandles
                               do:
                                               [:h |
                                               (GDILibrary
 
lineTo: h
 
x: aPoint x
 
y: aPoint y)
                                                               ifFalse:
 
[anError := KernelLibrary getLastError.
 
(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED"
 
ifFalse: [^self osError].
 
self osNotification]].
                ^location := aPoint rounded
               
Original:
line: aPoint
        "Private - Draw a line from the current location
        to aPoint.  Answer the new location."
    self allHandles do: [ :h |
        ( GDILibrary lineTo: h x: aPoint x y: aPoint y )
            ifFalse: [ ^self osError ] ].
    ^location := aPoint rounded

Is this a good fix?
Or shall I reimplement the osError on Pen or GraphicsTool and test
there?

We have already chanced three places where we call
GDILibrary
         stretchBlt: destDC
         x: x1
         y: y1
         dWidth: dWidth
         dHeight: dHeight
         srcDC: srcDC
         xSrc: x2
         ySrc: y2
         sWidth: sWidth
         sHeight: sHeight
         rop: aRopConstant
and just call "^self osNotification" instead of "^self osError " when
stretchBlt... return false.

And we can keep on changing one place after another, but I would like to
"just fix it" :-)

Regards

/Kjell

Kjell H. Ulstad
Arkitekt. Systemeier Paga/R&D
www.bluegarden.no

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: Access is denied. (OS error 16r5)

Carl Gundel-3
You could just reimplement osError in GraphicsTool to ignore the access is
denied error.

-Carl

GraphicsTool>>osError
"Report the error unless it is an access denied error (value of 5)."
        | theLastError |
        (theLastError := self lastOsError) = 5 ifTrue: [ ^ self ].
        ^self osError: theLastError

-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise
[mailto:[hidden email]] On Behalf Of Kjell Harald Ulstad
Sent: Friday, April 29, 2011 10:06 AM
To: [hidden email]
Subject: Access is denied. (OS error 16r5)

Hi folks.

Occasionally, we encounter the following error: Runtime error: Access is
denied. (OS error 16r5).
The error pop up when a Screensaver is running.
Probably because VSE tries to write to the screen and Microsoft have
changed the return value when a Screensaver is running  ;-)
The error log tells us that this has to do with GraphicsTool>>line:
(and other places...)
I've come up with a proposal for a solution (shown below the error log)
but is it a better way to solve it?

Error log:

Runtime error: Access is denied. (OS error 16r5)

Error(Exception)>>defaultAction
Error(Exception)>>activateHandler: <anUndefinedObject>
Error(Exception)>>handle
Error(Exception)>>signal
Error class(Exception class)>>signal: <'Access is denied. (O...'>
Pen(Object)>>osError: <5>
Pen(Object)>>osError
[] in GraphicsTool>>line:
Array(IndexedCollection)>>do: <aBlockClosure>
Pen(GraphicsTool)>>line: <aPoint>
Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint>
Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in>
CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle>
CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle>
clipRect: <aRectangle>
[] in CPSubPane>>display
CX3DTextFrame(Window)>>doGraphics: <aBlockClosure>
CX3DTextFrame(CPSubPane)>>display
CX3DTextFrame(Window)>>display: <aRectangle>
CX3DTextFrame(Window)>>wmPaint: <0> with: <0>
NotificationManager>>notify: <aWinMessage>
NotificationManager>>notifyRecursive
NotificationManager>>recursiveMessage
SystemDictionary>>recursiveMessage
SystemDictionary>>launch
NotificationManager>>readWinQueue
NotificationManager>>runEventLoop
Message>>perform
Message>>evaluate
Process>>safelyEvaluate: <aMessage>

The cause seems to be '^self osError' and below is a proposal for a
solution:

line: aPoint
                "Private - Draw a line from the current location
        to aPoint.  Answer the new location."

                | anError |
                self allHandles
                               do:
                                               [:h |
                                               (GDILibrary
 
lineTo: h
 
x: aPoint x
 
y: aPoint y)
                                                               ifFalse:
 
[anError := KernelLibrary getLastError.
 
(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED"
 
ifFalse: [^self osError].
 
self osNotification]].
                ^location := aPoint rounded
               
Original:
line: aPoint
        "Private - Draw a line from the current location
        to aPoint.  Answer the new location."
    self allHandles do: [ :h |
        ( GDILibrary lineTo: h x: aPoint x y: aPoint y )
            ifFalse: [ ^self osError ] ].
    ^location := aPoint rounded

Is this a good fix?
Or shall I reimplement the osError on Pen or GraphicsTool and test
there?

We have already chanced three places where we call
GDILibrary
         stretchBlt: destDC
         x: x1
         y: y1
         dWidth: dWidth
         dHeight: dHeight
         srcDC: srcDC
         xSrc: x2
         ySrc: y2
         sWidth: sWidth
         sHeight: sHeight
         rop: aRopConstant
and just call "^self osNotification" instead of "^self osError " when
stretchBlt... return false.

And we can keep on changing one place after another, but I would like to
"just fix it" :-)

Regards

/Kjell

Kjell H. Ulstad
Arkitekt. Systemeier Paga/R&D
www.bluegarden.no

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: Access is denied. (OS error 16r5)

Andreas Rosenberg
Does you drawing code use the graphicsTool that is getting a
DC from the beginPaint? My assumption is, you are using a
pen that is connected to the Display device context.
It is bad style to use the "Display pen" when drawing inside
a window and it will result in the problems you are experiencing.

The Display device context will report access denied errors
while screen savers are active and for other situations.

Using pens that are connected to a DC returned by BeginPaint
or GetDC(NULL) will not cause any problem for situations, when
the Display DC is being locked.

Regards

  Andreas

Andreas Rosenberg | eMail: [hidden email]
APIS GmbH         | Phone: +49 9482 9415-0
Im Haslet 42      | Fax: +49 9482 9415-55
93086 Worth/D     | WWW: <http://www.apis.de/>
Germany           | <http://www.fmea.de/>

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: Access is denied. (OS error 16r5)

Claus Kick
In reply to this post by Kjell Harald Ulstad
Wasnt there an official "patch" for this?



-- 
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. 
Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. 
Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy. 
More clearly, on the narrow path between lunacy and panic. 
Right around the corner of  fear of death, 
not far away from idiocy and insanity."

-----Ursprüngliche Nachricht-----
Von: "Kjell Harald Ulstad" <[hidden email]>
Gesendet: 29.04.2011 16:06:02
An: [hidden email]
Betreff: [VSWE-L] Access is denied. (OS error 16r5)

>Hi folks.
>
>Occasionally, we encounter the following error: Runtime error: Access is
>denied. (OS error 16r5).
>The error pop up when a Screensaver is running.
>Probably because VSE tries to write to the screen and Microsoft have
>changed the return value when a Screensaver is running ;-)
>The error log tells us that this has to do with GraphicsTool>>line:
>(and other places...)
>I've come up with a proposal for a solution (shown below the error log)
>but is it a better way to solve it?
>
>Error log:
>
>Runtime error: Access is denied. (OS error 16r5)
>
>Error(Exception)>>defaultAction
>Error(Exception)>>activateHandler: <anUndefinedObject>
>Error(Exception)>>handle
>Error(Exception)>>signal
>Error class(Exception class)>>signal: <'Access is denied. (O...'>
>Pen(Object)>>osError: <5>
>Pen(Object)>>osError
>[] in GraphicsTool>>line:
>Array(IndexedCollection)>>do: <aBlockClosure>
>Pen(GraphicsTool)>>line: <aPoint>
>Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint>
>Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in>
>CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle>
>CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle>
>clipRect: <aRectangle>
>[] in CPSubPane>>display
>CX3DTextFrame(Window)>>doGraphics: <aBlockClosure>
>CX3DTextFrame(CPSubPane)>>display
>CX3DTextFrame(Window)>>display: <aRectangle>
>CX3DTextFrame(Window)>>wmPaint: <0> with: <0>
>NotificationManager>>notify: <aWinMessage>
>NotificationManager>>notifyRecursive
>NotificationManager>>recursiveMessage
>SystemDictionary>>recursiveMessage
>SystemDictionary>>launch
>NotificationManager>>readWinQueue
>NotificationManager>>runEventLoop
>Message>>perform
>Message>>evaluate
>Process>>safelyEvaluate: <aMessage>
>
>The cause seems to be '^self osError' and below is a proposal for a
>solution:
>
>line: aPoint
> "Private - Draw a line from the current location
> to aPoint. Answer the new location."
>
> | anError |
> self allHandles
> do:
> [:h |
> (GDILibrary
>
>lineTo: h
>
>x: aPoint x
>
>y: aPoint y)
> ifFalse:
>
>[anError := KernelLibrary getLastError.
>
>(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED"
>
>ifFalse: [^self osError].
>
>self osNotification]].
> ^location := aPoint rounded
>
>Original:
>line: aPoint
> "Private - Draw a line from the current location
> to aPoint. Answer the new location."
> self allHandles do: [ :h |
> ( GDILibrary lineTo: h x: aPoint x y: aPoint y )
> ifFalse: [ ^self osError ] ].
> ^location := aPoint rounded
>
>Is this a good fix?
>Or shall I reimplement the osError on Pen or GraphicsTool and test
>there?
>
>We have already chanced three places where we call
>GDILibrary
> stretchBlt: destDC
> x: x1
> y: y1
> dWidth: dWidth
> dHeight: dHeight
> srcDC: srcDC
> xSrc: x2
> ySrc: y2
> sWidth: sWidth
> sHeight: sHeight
> rop: aRopConstant
>and just call "^self osNotification" instead of "^self osError " when
>stretchBlt... return false.
>
>And we can keep on changing one place after another, but I would like to
>"just fix it" :-)
>
>Regards
>
>/Kjell
>
>Kjell H. Ulstad
>Arkitekt. Systemeier Paga/R&D
>www.bluegarden.no
>
>*** this signature added by listserv ***
>*** Visit http://www.listserv.dfn.de/archives/vswe-l.html ***
>*** for archive browsing and VSWE-L membership management ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: Access is denied. (OS error 16r5)

Holm-Kjetil Holmsen-2
Yes, there was:  V352666w.  
That patch fixed the following methods:

        Bitmap (class)>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:
        GraphicsTool>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:
        GraphicsTool>>stretchBlt:x:y:dWidth:dHeight:srcDC:xSrc:ySrc:sWidth:sHeight:rop:

by replacing  ^self osError  with  ^self osNotification.  

The accompanying text-file tells us that "... In all cases it is sufficient for VSE to ignore this error code."  However, as the text-file also states: ALL the graphics code is written to be sensitive to returned error codes from the underlying (Windows)

We have later fixed the following:
        Pen>>rectangleFilled:
                "Return self if there is an error."
        TextTool>>displayText:at:
                "Return self if there is an error.  
                Note that normal termination sets "place" (cursor position) to the right of the displayed text."
        CursorManager (class)>>cursorPosition
                "Return 0@0 if there is an error.
                Note that normal termination returns the actual (hardware) cursor position!"

Note that the last "fix" might actually have introduced an error (as I now see it)!  Users of that method now gets 0@0 instead of "the real cursor position" (which I guess sort of "doesn't exist" when the screen is locked).  Sort of the same argument can be said of the "fix" to TextTool>>displayText:at:  -  the invariant of updating "place" might be broken (or is it? If the graphics returned an error code, did the (underlying graphics) "place" update?).  It might be better to do "self osNotification", but I am not sure about this - actually far from.  Does anyone out there have any ideas or "gut feelings" about this?

One of the big problems with this (kind of) bug, is that it's next to impossible to provoke.  After filing in the V352666w fix, most problems in the development image went away.  And we have not been able to provoke these errors in the production image.  The production image is served to our customers as a Citrix Published Application.  Just starting the (test-) application on a test server and locking the screen (or letting the screen-saver do it) hasn't provoked the error so far.  One customer that has problems with this error actually has a "company Citrix Desktop" that they log on to that our "Citrix application" in turn is Published in to.  (Arrgh...)


Holm-Kjetil Holmsen
Senior Software Engineer
www.bluegarden.no


-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Claus Kick
Sent: 2. mai 2011 12:40
To: [hidden email]
Subject: Re: Access is denied. (OS error 16r5)

Wasnt there an official "patch" for this?



--
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of  fear of death, not far away from idiocy and insanity."

-----Ursprüngliche Nachricht-----
Von: "Kjell Harald Ulstad" <[hidden email]>
Gesendet: 29.04.2011 16:06:02
An: [hidden email]
Betreff: [VSWE-L] Access is denied. (OS error 16r5)

>Hi folks.
>
>Occasionally, we encounter the following error: Runtime error: Access
>is denied. (OS error 16r5).
>The error pop up when a Screensaver is running.
>Probably because VSE tries to write to the screen and Microsoft have
>changed the return value when a Screensaver is running ;-) The error
>log tells us that this has to do with GraphicsTool>>line:
>(and other places...)
>I've come up with a proposal for a solution (shown below the error log)
>but is it a better way to solve it?
>
>Error log:
>
>Runtime error: Access is denied. (OS error 16r5)
>
>Error(Exception)>>defaultAction
>Error(Exception)>>activateHandler: <anUndefinedObject>
>Error(Exception)>>handle Error(Exception)>>signal Error class(Exception
>class)>>signal: <'Access is denied. (O...'>
>Pen(Object)>>osError: <5>
>Pen(Object)>>osError
>[] in GraphicsTool>>line:
>Array(IndexedCollection)>>do: <aBlockClosure>
>Pen(GraphicsTool)>>line: <aPoint>
>Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint>
>Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in>
>CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle>
>CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle>
>clipRect: <aRectangle>
>[] in CPSubPane>>display
>CX3DTextFrame(Window)>>doGraphics: <aBlockClosure>
>CX3DTextFrame(CPSubPane)>>display
>CX3DTextFrame(Window)>>display: <aRectangle>
>CX3DTextFrame(Window)>>wmPaint: <0> with: <0>
>NotificationManager>>notify: <aWinMessage> notifyRecursive
>NotificationManager>>recursiveMessage
>SystemDictionary>>recursiveMessage
>SystemDictionary>>launch
>NotificationManager>>readWinQueue
>NotificationManager>>runEventLoop
>Message>>perform
>Message>>evaluate
>Process>>safelyEvaluate: <aMessage>
>
>The cause seems to be '^self osError' and below is a proposal for a
>solution:
>
>line: aPoint
> "Private - Draw a line from the current location  to aPoint. Answer
>the new location."
>
> | anError |
> self allHandles
> do:
> [:h |
> (GDILibrary
>
>lineTo: h
>
>x: aPoint x
>
>y: aPoint y)
> ifFalse:
>
>[anError := KernelLibrary getLastError.
>
>(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED"
>
>ifFalse: [^self osError].
>
>self osNotification]].
> ^location := aPoint rounded
>
>Original:
>line: aPoint
> "Private - Draw a line from the current location  to aPoint. Answer
>the new location."
> self allHandles do: [ :h |
> ( GDILibrary lineTo: h x: aPoint x y: aPoint y )
> ifFalse: [ ^self osError ] ].
> ^location := aPoint rounded
>
>Is this a good fix?
>Or shall I reimplement the osError on Pen or GraphicsTool and test
>there?
>
>We have already chanced three places where we call GDILibrary
> stretchBlt: destDC
> x: x1
> y: y1
> dWidth: dWidth
> dHeight: dHeight
> srcDC: srcDC
> xSrc: x2
> ySrc: y2
> sWidth: sWidth
> sHeight: sHeight
> rop: aRopConstant
>and just call "^self osNotification" instead of "^self osError " when
>stretchBlt... return false.
>
>And we can keep on changing one place after another, but I would like
>to "just fix it" :-)
>
>Regards
>
>/Kjell
>
>Kjell H. Ulstad
>Arkitekt. Systemeier Paga/R&D
>www.bluegarden.no
>
>*** this signature added by listserv ***
>*** Visit http://www.listserv.dfn.de/archives/vswe-l.html ***
>*** for archive browsing and VSWE-L membership management ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

AW: Access is denied. (OS error 16r5)

frank.lesser
Couldn't resist - the fix is not serious - it should be done right - not in
just ignoring an error condition - there is a simple way to do it right -
register with the powerChanged:with: event of SessionModel current - when
you need you deny the Screensaver you need to change
SystemWindow>>wmPowerbroadcast: wparam with: lparam not to return nil ( e.g
the result of the event).


-----Ursprüngliche Nachricht-----
Von: Using Visual Smalltalk for Windows/Enterprise
[mailto:[hidden email]] Im Auftrag von Holm-Kjetil Holmsen
Gesendet: Montag, 2. Mai 2011 15:02
An: [hidden email]
Betreff: Re: Access is denied. (OS error 16r5)

Yes, there was:  V352666w.  
That patch fixed the following methods:

        Bitmap (class)>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:
        GraphicsTool>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:
       
GraphicsTool>>stretchBlt:x:y:dWidth:dHeight:srcDC:xSrc:ySrc:sWidth:sHeight:r
op:

by replacing  ^self osError  with  ^self osNotification.  

The accompanying text-file tells us that "... In all cases it is sufficient
for VSE to ignore this error code."  However, as the text-file also states:
ALL the graphics code is written to be sensitive to returned error codes
from the underlying (Windows)


We have later fixed the following:
        Pen>>rectangleFilled:
                "Return self if there is an error."
        TextTool>>displayText:at:
                "Return self if there is an error.  
                Note that normal termination sets "place" (cursor position)
to the right of the displayed text."
        CursorManager (class)>>cursorPosition
                "Return 0@0 if there is an error.
                Note that normal termination returns the actual (hardware)
cursor position!"

Note that the last "fix" might actually have introduced an error (as I now
see it)!  Users of that method now gets 0@0 instead of "the real cursor
position" (which I guess sort of "doesn't exist" when the screen is locked).
Sort of the same argument can be said of the "fix" to
TextTool>>displayText:at:  -  the invariant of updating "place" might be
broken (or is it? If the graphics returned an error code, did the
(underlying graphics) "place" update?).  It might be better to do "self
osNotification", but I am not sure about this - actually far from.  Does
anyone out there have any ideas or "gut feelings" about this?

One of the big problems with this (kind of) bug, is that it's next to
impossible to provoke.  After filing in the V352666w fix, most problems in
the development image went away.  And we have not been able to provoke these
errors in the production image.  The production image is served to our
customers as a Citrix Published Application.  Just starting the (test-)
application on a test server and locking the screen (or letting the
screen-saver do it) hasn't provoked the error so far.  One customer that has
problems with this error actually has a "company Citrix Desktop" that they
log on to that our "Citrix application" in turn is Published in to.
(Arrgh...)


Holm-Kjetil Holmsen
Senior Software Engineer
www.bluegarden.no


-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise
[mailto:[hidden email]] On Behalf Of Claus Kick
Sent: 2. mai 2011 12:40
To: [hidden email]
Subject: Re: Access is denied. (OS error 16r5)

Wasnt there an official "patch" for this?



--
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf.
Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy.
More clearly, on the narrow path between lunacy and panic.
Right around the corner of  fear of death,
not far away from idiocy and insanity."

-----Ursprüngliche Nachricht-----
Von: "Kjell Harald Ulstad" <[hidden email]>
Gesendet: 29.04.2011 16:06:02
An: [hidden email]
Betreff: [VSWE-L] Access is denied. (OS error 16r5)

>Hi folks.
>
>Occasionally, we encounter the following error: Runtime error: Access
>is denied. (OS error 16r5).
>The error pop up when a Screensaver is running.
>Probably because VSE tries to write to the screen and Microsoft have
>changed the return value when a Screensaver is running ;-) The error
>log tells us that this has to do with GraphicsTool>>line:
>(and other places...)
>I've come up with a proposal for a solution (shown below the error log)
>but is it a better way to solve it?
>
>Error log:
>
>Runtime error: Access is denied. (OS error 16r5)
>
>Error(Exception)>>defaultAction
>Error(Exception)>>activateHandler: <anUndefinedObject>
>Error(Exception)>>handle Error(Exception)>>signal Error class(Exception
>class)>>signal: <'Access is denied. (O...'>
>Pen(Object)>>osError: <5>
>Pen(Object)>>osError
>[] in GraphicsTool>>line:
>Array(IndexedCollection)>>do: <aBlockClosure>
>Pen(GraphicsTool)>>line: <aPoint>
>Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint>
>Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in>
>CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle>
>CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle>
>clipRect: <aRectangle>
>[] in CPSubPane>>display
>CX3DTextFrame(Window)>>doGraphics: <aBlockClosure>
>CX3DTextFrame(CPSubPane)>>display
>CX3DTextFrame(Window)>>display: <aRectangle>
>CX3DTextFrame(Window)>>wmPaint: <0> with: <0>
>NotificationManager>>notify: <aWinMessage> notifyRecursive
>NotificationManager>>recursiveMessage
>SystemDictionary>>recursiveMessage
>SystemDictionary>>launch
>NotificationManager>>readWinQueue
>NotificationManager>>runEventLoop
>Message>>perform
>Message>>evaluate
>Process>>safelyEvaluate: <aMessage>
>
>The cause seems to be '^self osError' and below is a proposal for a
>solution:
>
>line: aPoint
> "Private - Draw a line from the current location  to aPoint. Answer
>the new location."
>
> | anError |
> self allHandles
> do:
> [:h |
> (GDILibrary
>
>lineTo: h
>
>x: aPoint x
>
>y: aPoint y)
> ifFalse:
>
>[anError := KernelLibrary getLastError.
>
>(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED"
>
>ifFalse: [^self osError].
>
>self osNotification]].
> ^location := aPoint rounded
>
>Original:
>line: aPoint
> "Private - Draw a line from the current location  to aPoint. Answer
>the new location."
> self allHandles do: [ :h |
> ( GDILibrary lineTo: h x: aPoint x y: aPoint y )
> ifFalse: [ ^self osError ] ].
> ^location := aPoint rounded
>
>Is this a good fix?
>Or shall I reimplement the osError on Pen or GraphicsTool and test
>there?
>
>We have already chanced three places where we call GDILibrary
> stretchBlt: destDC
> x: x1
> y: y1
> dWidth: dWidth
> dHeight: dHeight
> srcDC: srcDC
> xSrc: x2
> ySrc: y2
> sWidth: sWidth
> sHeight: sHeight
> rop: aRopConstant
>and just call "^self osNotification" instead of "^self osError " when
>stretchBlt... return false.
>
>And we can keep on changing one place after another, but I would like
>to "just fix it" :-)
>
>Regards
>
>/Kjell
>
>Kjell H. Ulstad
>Arkitekt. Systemeier Paga/R&D
>www.bluegarden.no
>
>*** this signature added by listserv ***
>*** Visit http://www.listserv.dfn.de/archives/vswe-l.html ***
>*** for archive browsing and VSWE-L membership management ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: Access is denied. (OS error 16r5)

Leandro Caniglia
Yep.

In addition to that I suggest taking care of things that might go messy: bitmap caches, etc.

This is an example of what we do:

powerChange: eventType
eventType = 'suspend request' ifTrue: [Notifier cleanUpAllMessages].
eventType = 'resume suspend' ifTrue: [
AlphaBitmap resetCache.
windows
do: [:w | (w isTopPane ifTrue: [w] ifFalse: [w mainWindow]) enableRedraw]]

/Leandro


On Mon, May 2, 2011 at 3:40 PM, Frank Lesser <[hidden email]> wrote:
Couldn't resist - the fix is not serious - it should be done right - not in
just ignoring an error condition - there is a simple way to do it right -
register with the powerChanged:with: event of SessionModel current - when
you need you deny the Screensaver you need to change
SystemWindow>>wmPowerbroadcast: wparam with: lparam not to return nil ( e.g
the result of the event).


-----Ursprüngliche Nachricht-----
Von: Using Visual Smalltalk for Windows/Enterprise
[mailto:[hidden email]] Im Auftrag von Holm-Kjetil Holmsen
Gesendet: Montag, 2. Mai 2011 15:02
Betreff: Re: Access is denied. (OS error 16r5)

Yes, there was:  V352666w.
That patch fixed the following methods:

       Bitmap (class)>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:
       GraphicsTool>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:

GraphicsTool>>stretchBlt:x:y:dWidth:dHeight:srcDC:xSrc:ySrc:sWidth:sHeight:r
op:

by replacing  ^self osError  with  ^self osNotification.

The accompanying text-file tells us that "... In all cases it is sufficient
for VSE to ignore this error code."  However, as the text-file also states:
ALL the graphics code is written to be sensitive to returned error codes
from the underlying (Windows)


We have later fixed the following:
       Pen>>rectangleFilled:
               "Return self if there is an error."
       TextTool>>displayText:at:
               "Return self if there is an error.
               Note that normal termination sets "place" (cursor position)
to the right of the displayed text."
       CursorManager (class)>>cursorPosition
               "Return 0@0 if there is an error.
               Note that normal termination returns the actual (hardware)
cursor position!"

Note that the last "fix" might actually have introduced an error (as I now
see it)!  Users of that method now gets 0@0 instead of "the real cursor
position" (which I guess sort of "doesn't exist" when the screen is locked).
Sort of the same argument can be said of the "fix" to
TextTool>>displayText:at:  -  the invariant of updating "place" might be
broken (or is it? If the graphics returned an error code, did the
(underlying graphics) "place" update?).  It might be better to do "self
osNotification", but I am not sure about this - actually far from.  Does
anyone out there have any ideas or "gut feelings" about this?

One of the big problems with this (kind of) bug, is that it's next to
impossible to provoke.  After filing in the V352666w fix, most problems in
the development image went away.  And we have not been able to provoke these
errors in the production image.  The production image is served to our
customers as a Citrix Published Application.  Just starting the (test-)
application on a test server and locking the screen (or letting the
screen-saver do it) hasn't provoked the error so far.  One customer that has
problems with this error actually has a "company Citrix Desktop" that they
log on to that our "Citrix application" in turn is Published in to.
(Arrgh...)


Holm-Kjetil Holmsen
Senior Software Engineer
www.bluegarden.no


-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise
[mailto:[hidden email]] On Behalf Of Claus Kick
Sent: 2. mai 2011 12:40
To: [hidden email]
Subject: Re: Access is denied. (OS error 16r5)

Wasnt there an official "patch" for this?



--
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf.
Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy.
More clearly, on the narrow path between lunacy and panic.
Right around the corner of  fear of death,
not far away from idiocy and insanity."

-----Ursprüngliche Nachricht-----
Von: "Kjell Harald Ulstad" <[hidden email]>
Gesendet: 29.04.2011 16:06:02
An: [hidden email]
Betreff: [VSWE-L] Access is denied. (OS error 16r5)

>Hi folks.
>
>Occasionally, we encounter the following error: Runtime error: Access
>is denied. (OS error 16r5).
>The error pop up when a Screensaver is running.
>Probably because VSE tries to write to the screen and Microsoft have
>changed the return value when a Screensaver is running ;-) The error
>log tells us that this has to do with GraphicsTool>>line:
>(and other places...)
>I've come up with a proposal for a solution (shown below the error log)
>but is it a better way to solve it?
>
>Error log:
>
>Runtime error: Access is denied. (OS error 16r5)
>
>Error(Exception)>>defaultAction
>Error(Exception)>>activateHandler: <anUndefinedObject>
>Error(Exception)>>handle Error(Exception)>>signal Error class(Exception
>class)>>signal: <'Access is denied. (O...'>
>Pen(Object)>>osError: <5>
>Pen(Object)>>osError
>[] in GraphicsTool>>line:
>Array(IndexedCollection)>>do: <aBlockClosure>
>Pen(GraphicsTool)>>line: <aPoint>
>Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint>
>Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in>
>CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle>
>CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle>
>clipRect: <aRectangle>
>[] in CPSubPane>>display
>CX3DTextFrame(Window)>>doGraphics: <aBlockClosure>
>CX3DTextFrame(CPSubPane)>>display
>CX3DTextFrame(Window)>>display: <aRectangle>
>CX3DTextFrame(Window)>>wmPaint: <0> with: <0>
>NotificationManager>>notify: <aWinMessage> notifyRecursive
>NotificationManager>>recursiveMessage
>SystemDictionary>>recursiveMessage
>SystemDictionary>>launch
>NotificationManager>>readWinQueue
>NotificationManager>>runEventLoop
>Message>>perform
>Message>>evaluate
>Process>>safelyEvaluate: <aMessage>
>
>The cause seems to be '^self osError' and below is a proposal for a
>solution:
>
>line: aPoint
> "Private - Draw a line from the current location  to aPoint. Answer
>the new location."
>
> | anError |
> self allHandles
> do:
> [:h |
> (GDILibrary
>
>lineTo: h
>
>x: aPoint x
>
>y: aPoint y)
> ifFalse:
>
>[anError := KernelLibrary getLastError.
>
>(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED"
>
>ifFalse: [^self osError].
>
>self osNotification]].
> ^location := aPoint rounded
>
>Original:
>line: aPoint
> "Private - Draw a line from the current location  to aPoint. Answer
>the new location."
> self allHandles do: [ :h |
> ( GDILibrary lineTo: h x: aPoint x y: aPoint y )
> ifFalse: [ ^self osError ] ].
> ^location := aPoint rounded
>
>Is this a good fix?
>Or shall I reimplement the osError on Pen or GraphicsTool and test
>there?
>
>We have already chanced three places where we call GDILibrary
> stretchBlt: destDC
> x: x1
> y: y1
> dWidth: dWidth
> dHeight: dHeight
> srcDC: srcDC
> xSrc: x2
> ySrc: y2
> sWidth: sWidth
> sHeight: sHeight
> rop: aRopConstant
>and just call "^self osNotification" instead of "^self osError " when
>stretchBlt... return false.
>
>And we can keep on changing one place after another, but I would like
>to "just fix it" :-)
>
>Regards
>
>/Kjell
>
>Kjell H. Ulstad
>Arkitekt. Systemeier Paga/R&D
>www.bluegarden.no
>
>*** this signature added by listserv ***
>*** Visit http://www.listserv.dfn.de/archives/vswe-l.html ***
>*** for archive browsing and VSWE-L membership management ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
Reply | Threaded
Open this post in threaded view
|

Re: Access is denied. (OS error 16r5)

Andreas Rosenberg
Screensavers are only one possiblity where the screen will be inaccessible.
I think, in general you should change your implementation to avoid usage of the
"Display pen" (aka display DC) at all.
 
There are various other situations:
 
- you can do a "switch user" in your OS - this will keep your program running, but the screen device
  will not be accessible, because a different session will be connected to the display DC.
  I think similar situations can happen, when working with Citrix/Terminal Server.
 
- if your app will be started as a service or via certain registry "run keys" and nobody does
  a login, the display DC will not be accessible, too.
 
- if you are using multiple monitors, the "Display pen" will be the device for the primary monitor.
  But the user can switch the display for primary monitor, if the graphics card has multiple heads.
  I never really examined this situation, but it could be, that the cached handle to the display DC will become invalid.
...
 
Regards
 
  Andreas
 
-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]]On Behalf Of Leandro Caniglia
Sent: Montag, 2. Mai 2011 22:25
To: [hidden email]
Subject: Re: Access is denied. (OS error 16r5)

Yep.

In addition to that I suggest taking care of things that might go messy: bitmap caches, etc.

This is an example of what we do:

powerChange: eventType
eventType = 'suspend request' ifTrue: [Notifier cleanUpAllMessages].
eventType = 'resume suspend' ifTrue: [
AlphaBitmap resetCache.
windows
do: [:w | (w isTopPane ifTrue: [w] ifFalse: [w mainWindow]) enableRedraw]]

/Leandro


On Mon, May 2, 2011 at 3:40 PM, Frank Lesser <[hidden email]> wrote:
Couldn't resist - the fix is not serious - it should be done right - not in
just ignoring an error condition - there is a simple way to do it right -
register with the powerChanged:with: event of SessionModel current - when
you need you deny the Screensaver you need to change
SystemWindow>>wmPowerbroadcast: wparam with: lparam not to return nil ( e.g
the result of the event).


-----Ursprüngliche Nachricht-----
Von: Using Visual Smalltalk for Windows/Enterprise
[mailto:[hidden email]] Im Auftrag von Holm-Kjetil Holmsen
Gesendet: Montag, 2. Mai 2011 15:02
Betreff: Re: Access is denied. (OS error 16r5)

Yes, there was:  V352666w.
That patch fixed the following methods:

       Bitmap (class)>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:
       GraphicsTool>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:

GraphicsTool>>stretchBlt:x:y:dWidth:dHeight:srcDC:xSrc:ySrc:sWidth:sHeight:r
op:

by replacing  ^self osError  with  ^self osNotification.

The accompanying text-file tells us that "... In all cases it is sufficient
for VSE to ignore this error code."  However, as the text-file also states:
ALL the graphics code is written to be sensitive to returned error codes
from the underlying (Windows)


We have later fixed the following:
       Pen>>rectangleFilled:
               "Return self if there is an error."
       TextTool>>displayText:at:
               "Return self if there is an error.
               Note that normal termination sets "place" (cursor position)
to the right of the displayed text."
       CursorManager (class)>>cursorPosition
               "Return 0@0 if there is an error.
               Note that normal termination returns the actual (hardware)
cursor position!"

Note that the last "fix" might actually have introduced an error (as I now
see it)!  Users of that method now gets 0@0 instead of "the real cursor
position" (which I guess sort of "doesn't exist" when the screen is locked).
Sort of the same argument can be said of the "fix" to
TextTool>>displayText:at:  -  the invariant of updating "place" might be
broken (or is it? If the graphics returned an error code, did the
(underlying graphics) "place" update?).  It might be better to do "self
osNotification", but I am not sure about this - actually far from.  Does
anyone out there have any ideas or "gut feelings" about this?

One of the big problems with this (kind of) bug, is that it's next to
impossible to provoke.  After filing in the V352666w fix, most problems in
the development image went away.  And we have not been able to provoke these
errors in the production image.  The production image is served to our
customers as a Citrix Published Application.  Just starting the (test-)
application on a test server and locking the screen (or letting the
screen-saver do it) hasn't provoked the error so far.  One customer that has
problems with this error actually has a "company Citrix Desktop" that they
log on to that our "Citrix application" in turn is Published in to.
(Arrgh...)


Holm-Kjetil Holmsen
Senior Software Engineer
www.bluegarden.no


-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise
[mailto:[hidden email]] On Behalf Of Claus Kick
Sent: 2. mai 2011 12:40
To: [hidden email]
Subject: Re: Access is denied. (OS error 16r5)

Wasnt there an official "patch" for this?



--
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf.
Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy.
More clearly, on the narrow path between lunacy and panic.
Right around the corner of  fear of death,
not far away from idiocy and insanity."

-----Ursprüngliche Nachricht-----
Von: "Kjell Harald Ulstad" <[hidden email]>
Gesendet: 29.04.2011 16:06:02
An: [hidden email]
Betreff: [VSWE-L] Access is denied. (OS error 16r5)

>Hi folks.
>
>Occasionally, we encounter the following error: Runtime error: Access
>is denied. (OS error 16r5).
>The error pop up when a Screensaver is running.
>Probably because VSE tries to write to the screen and Microsoft have
>changed the return value when a Screensaver is running ;-) The error
>log tells us that this has to do with GraphicsTool>>line:
>(and other places...)
>I've come up with a proposal for a solution (shown below the error log)
>but is it a better way to solve it?
>
>Error log:
>
>Runtime error: Access is denied. (OS error 16r5)
>
>Error(Exception)>>defaultAction
>Error(Exception)>>activateHandler: <anUndefinedObject>
>Error(Exception)>>handle Error(Exception)>>signal Error class(Exception
>class)>>signal: <'Access is denied. (O...'>
>Pen(Object)>>osError: <5>
>Pen(Object)>>osError
>[] in GraphicsTool>>line:
>Array(IndexedCollection)>>do: <aBlockClosure>
>Pen(GraphicsTool)>>line: <aPoint>
>Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint>
>Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in>
>CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle>
>CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle>
>clipRect: <aRectangle>
>[] in CPSubPane>>display
>CX3DTextFrame(Window)>>doGraphics: <aBlockClosure>
>CX3DTextFrame(CPSubPane)>>display
>CX3DTextFrame(Window)>>display: <aRectangle>
>CX3DTextFrame(Window)>>wmPaint: <0> with: <0>
>NotificationManager>>notify: <aWinMessage> notifyRecursive
>NotificationManager>>recursiveMessage
>SystemDictionary>>recursiveMessage
>SystemDictionary>>launch
>NotificationManager>>readWinQueue
>NotificationManager>>runEventLoop
>Message>>perform
>Message>>evaluate
>Process>>safelyEvaluate: <aMessage>
>
>The cause seems to be '^self osError' and below is a proposal for a
>solution:
>
>line: aPoint
> "Private - Draw a line from the current location  to aPoint. Answer
>the new location."
>
> | anError |
> self allHandles
> do:
> [:h |
> (GDILibrary
>
>lineTo: h
>
>x: aPoint x
>
>y: aPoint y)
> ifFalse:
>
>[anError := KernelLibrary getLastError.
>
>(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED"
>
>ifFalse: [^self osError].
>
>self osNotification]].
> ^location := aPoint rounded
>
>Original:
>line: aPoint
> "Private - Draw a line from the current location  to aPoint. Answer
>the new location."
> self allHandles do: [ :h |
> ( GDILibrary lineTo: h x: aPoint x y: aPoint y )
> ifFalse: [ ^self osError ] ].
> ^location := aPoint rounded
>
>Is this a good fix?
>Or shall I reimplement the osError on Pen or GraphicsTool and test
>there?
>
>We have already chanced three places where we call GDILibrary
> stretchBlt: destDC
> x: x1
> y: y1
> dWidth: dWidth
> dHeight: dHeight
> srcDC: srcDC
> xSrc: x2
> ySrc: y2
> sWidth: sWidth
> sHeight: sHeight
> rop: aRopConstant
>and just call "^self osNotification" instead of "^self osError " when
>stretchBlt... return false.
>
>And we can keep on changing one place after another, but I would like
>to "just fix it" :-)
>
>Regards
>
>/Kjell
>
>Kjell H. Ulstad
>Arkitekt. Systemeier Paga/R&D
>www.bluegarden.no
>
>*** this signature added by listserv ***
>*** Visit http://www.listserv.dfn.de/archives/vswe-l.html ***
>*** for archive browsing and VSWE-L membership management ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
Reply | Threaded
Open this post in threaded view
|

Re: AW: Access is denied. (OS error 16r5)

Claus Kick
In reply to this post by Kjell Harald Ulstad
That is why I called it a "patch" instead of a patch.

-- 
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. 
Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. 
Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy. 
More clearly, on the narrow path between lunacy and panic. 
Right around the corner of  fear of death, 
not far away from idiocy and insanity."

-----Ursprüngliche Nachricht-----
Von: "Frank Lesser" <[hidden email]>
Gesendet: 02.05.2011 20:40:55
An: [hidden email]
Betreff: [VSWE-L] AW: Access is denied. (OS error 16r5)

>Couldn't resist - the fix is not serious - it should be done right - not in
>just ignoring an error condition - there is a simple way to do it right -
>register with the powerChanged:with: event of SessionModel current - when
>you need you deny the Screensaver you need to change
>SystemWindow>>wmPowerbroadcast: wparam with: lparam not to return nil ( e.g
>the result of the event).
>
>
>-----Ursprüngliche Nachricht-----
>Von: Using Visual Smalltalk for Windows/Enterprise
>[mailto:[hidden email]] Im Auftrag von Holm-Kjetil Holmsen
>Gesendet: Montag, 2. Mai 2011 15:02
>An: [hidden email]
>Betreff: Re: Access is denied. (OS error 16r5)
>
>Yes, there was: V352666w.
>That patch fixed the following methods:
>
> Bitmap (class)>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:
> GraphicsTool>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:
>
>GraphicsTool>>stretchBlt:x:y:dWidth:dHeight:srcDC:xSrc:ySrc:sWidth:sHeight:r
>op:
>
>by replacing ^self osError with ^self osNotification.
>
>The accompanying text-file tells us that "... In all cases it is sufficient
>for VSE to ignore this error code." However, as the text-file also states:
>ALL the graphics code is written to be sensitive to returned error codes
>from the underlying (Windows)
>
>
>We have later fixed the following:
> Pen>>rectangleFilled:
> "Return self if there is an error."
> TextTool>>displayText:at:
> "Return self if there is an error.
> Note that normal termination sets "place" (cursor position)
>to the right of the displayed text."
> CursorManager (class)>>cursorPosition
> "Return 0@0 if there is an error.
> Note that normal termination returns the actual (hardware)
>cursor position!"
>
>Note that the last "fix" might actually have introduced an error (as I now
>see it)! Users of that method now gets 0@0 instead of "the real cursor
>position" (which I guess sort of "doesn't exist" when the screen is locked).
>Sort of the same argument can be said of the "fix" to
>TextTool>>displayText:at: - the invariant of updating "place" might be
>broken (or is it? If the graphics returned an error code, did the
>(underlying graphics) "place" update?). It might be better to do "self
>osNotification", but I am not sure about this - actually far from. Does
>anyone out there have any ideas or "gut feelings" about this?
>
>One of the big problems with this (kind of) bug, is that it's next to
>impossible to provoke. After filing in the V352666w fix, most problems in
>the development image went away. And we have not been able to provoke these
>errors in the production image. The production image is served to our
>customers as a Citrix Published Application. Just starting the (test-)
>application on a test server and locking the screen (or letting the
>screen-saver do it) hasn't provoked the error so far. One customer that has
>problems with this error actually has a "company Citrix Desktop" that they
>log on to that our "Citrix application" in turn is Published in to.
>(Arrgh...)
>
>
>Holm-Kjetil Holmsen
>Senior Software Engineer
>www.bluegarden.no
>
>
>-----Original Message-----
>From: Using Visual Smalltalk for Windows/Enterprise
>[mailto:[hidden email]] On Behalf Of Claus Kick
>Sent: 2. mai 2011 12:40
>To: [hidden email]
>Subject: Re: Access is denied. (OS error 16r5)
>
>Wasnt there an official "patch" for this?
>
>
>
>--
>Claus Kick
>
>"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf.
>Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
>Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."
>
>"If you are looking for me: I am somewhere near to lunacy.
>More clearly, on the narrow path between lunacy and panic.
>Right around the corner of  fear of death,
>not far away from idiocy and insanity."
>
>-----Ursprüngliche Nachricht-----
>Von: "Kjell Harald Ulstad" <[hidden email]>
>Gesendet: 29.04.2011 16:06:02
>An: [hidden email]
>Betreff: [VSWE-L] Access is denied. (OS error 16r5)
>
>>Hi folks.
>>
>>Occasionally, we encounter the following error: Runtime error: Access
>>is denied. (OS error 16r5).
>>The error pop up when a Screensaver is running.
>>Probably because VSE tries to write to the screen and Microsoft have
>>changed the return value when a Screensaver is running ;-) The error
>>log tells us that this has to do with GraphicsTool>>line:
>>(and other places...)
>>I've come up with a proposal for a solution (shown below the error log)
>>but is it a better way to solve it?
>>
>>Error log:
>>
>>Runtime error: Access is denied. (OS error 16r5)
>>
>>Error(Exception)>>defaultAction
>>Error(Exception)>>activateHandler: <anUndefinedObject>
>>Error(Exception)>>handle Error(Exception)>>signal Error class(Exception
>>class)>>signal: <'Access is denied. (O...'>
>>Pen(Object)>>osError: <5>
>>Pen(Object)>>osError
>>[] in GraphicsTool>>line:
>>Array(IndexedCollection)>>do: <aBlockClosure>
>>Pen(GraphicsTool)>>line: <aPoint>
>>Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint>
>>Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in>
>>CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle>
>>CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle>
>>clipRect: <aRectangle>
>>[] in CPSubPane>>display
>>CX3DTextFrame(Window)>>doGraphics: <aBlockClosure>
>>CX3DTextFrame(CPSubPane)>>display
>>CX3DTextFrame(Window)>>display: <aRectangle>
>>CX3DTextFrame(Window)>>wmPaint: <0> with: <0>
>>NotificationManager>>notify: <aWinMessage> notifyRecursive
>>NotificationManager>>recursiveMessage
>>SystemDictionary>>recursiveMessage
>>SystemDictionary>>launch
>>NotificationManager>>readWinQueue
>>NotificationManager>>runEventLoop
>>Message>>perform
>>Message>>evaluate
>>Process>>safelyEvaluate: <aMessage>
>>
>>The cause seems to be '^self osError' and below is a proposal for a
>>solution:
>>
>>line: aPoint
>> "Private - Draw a line from the current location to aPoint. Answer
>>the new location."
>>
>> | anError |
>> self allHandles
>> do:
>> [:h |
>> (GDILibrary
>>
>>lineTo: h
>>
>>x: aPoint x
>>
>>y: aPoint y)
>> ifFalse:
>>
>>[anError := KernelLibrary getLastError.
>>
>>(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED"
>>
>>ifFalse: [^self osError].
>>
>>self osNotification]].
>> ^location := aPoint rounded
>>
>>Original:
>>line: aPoint
>> "Private - Draw a line from the current location to aPoint. Answer
>>the new location."
>> self allHandles do: [ :h |
>> ( GDILibrary lineTo: h x: aPoint x y: aPoint y )
>> ifFalse: [ ^self osError ] ].
>> ^location := aPoint rounded
>>
>>Is this a good fix?
>>Or shall I reimplement the osError on Pen or GraphicsTool and test
>>there?
>>
>>We have already chanced three places where we call GDILibrary
>> stretchBlt: destDC
>> x: x1
>> y: y1
>> dWidth: dWidth
>> dHeight: dHeight
>> srcDC: srcDC
>> xSrc: x2
>> ySrc: y2
>> sWidth: sWidth
>> sHeight: sHeight
>> rop: aRopConstant
>>and just call "^self osNotification" instead of "^self osError " when
>>stretchBlt... return false.
>>
>>And we can keep on changing one place after another, but I would like
>>to "just fix it" :-)
>>
>>Regards
>>
>>/Kjell
>>
>>Kjell H. Ulstad
>>Arkitekt. Systemeier Paga/R&D
>>www.bluegarden.no
>>
>>*** this signature added by listserv ***
>>*** Visit http://www.listserv.dfn.de/archives/vswe-l.html ***
>>*** for archive browsing and VSWE-L membership management ***
>
>*** this signature added by listserv ***
>*** Visit http://www.listserv.dfn.de/archives/vswe-l.html ***
>*** for archive browsing and VSWE-L membership management ***
>
>*** this signature added by listserv ***
>*** Visit http://www.listserv.dfn.de/archives/vswe-l.html ***
>*** for archive browsing and VSWE-L membership management ***
>
>*** this signature added by listserv ***
>*** Visit http://www.listserv.dfn.de/archives/vswe-l.html ***
>*** for archive browsing and VSWE-L membership management ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: Access is denied. (OS error 16r5)

Holm-Kjetil Holmsen-2
In reply to this post by Leandro Caniglia

Thanks to You both, Frank and Leandro!  

 

We’ll try this approach – and it is indeed a much more elegant solution than what we have done before!  (And thereby much more satisfying!)

 

The most furious thing about this problem is that it does not show itself in our development images, nor in the test-environment (which is set up as Citrix published applications, just as in production as far as I can tell).  It apparently only materializes itself for (some of) our customers (which are not “in house”, but the application is served from “in house”).  Needs for some “testing and prodding” to see if we actually can catch the right events, I would think – but that is the challenge…

 

I’ll – we’ll – keep the list posted as of how this goes.

 

Regards

 

Holm-Kjetil Holmsen

Senior software engineer

www.bluegarden.no

 

 

From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Leandro Caniglia
Sent: 2. mai 2011 22:25
To: [hidden email]
Subject: Re: Access is denied. (OS error 16r5)

 

Yep.

 

In addition to that I suggest taking care of things that might go messy: bitmap caches, etc.

 

This is an example of what we do:

 

powerChange: eventType

eventType = 'suspend request' ifTrue: [Notifier cleanUpAllMessages].

eventType = 'resume suspend' ifTrue: [

AlphaBitmap resetCache.

windows

do: [:w | (w isTopPane ifTrue: [w] ifFalse: [w mainWindow]) enableRedraw]]

 

/Leandro

 

 

On Mon, May 2, 2011 at 3:40 PM, Frank Lesser <[hidden email]> wrote:

Couldn't resist - the fix is not serious - it should be done right - not in
just ignoring an error condition - there is a simple way to do it right -
register with the powerChanged:with: event of SessionModel current - when
you need you deny the Screensaver you need to change
SystemWindow>>wmPowerbroadcast: wparam with: lparam not to return nil ( e.g
the result of the event).


-----Ursprüngliche Nachricht-----
Von: Using Visual Smalltalk for Windows/Enterprise
[mailto:[hidden email]] Im Auftrag von Holm-Kjetil Holmsen
Gesendet: Montag, 2. Mai 2011 15:02

Betreff: Re: Access is denied. (OS error 16r5)


Yes, there was:  V352666w.
That patch fixed the following methods:

       Bitmap (class)>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:
       GraphicsTool>>bitBlt:x:y:width:height:srcDC:xSrc:ySrc:rop:

GraphicsTool>>stretchBlt:x:y:dWidth:dHeight:srcDC:xSrc:ySrc:sWidth:sHeight:r
op:

by replacing  ^self osError  with  ^self osNotification.

The accompanying text-file tells us that "... In all cases it is sufficient
for VSE to ignore this error code."  However, as the text-file also states:
ALL the graphics code is written to be sensitive to returned error codes
from the underlying (Windows)


We have later fixed the following:
       Pen>>rectangleFilled:
               "Return self if there is an error."
       TextTool>>displayText:at:
               "Return self if there is an error.
               Note that normal termination sets "place" (cursor position)
to the right of the displayed text."
       CursorManager (class)>>cursorPosition
               "Return 0@0 if there is an error.
               Note that normal termination returns the actual (hardware)
cursor position!"

Note that the last "fix" might actually have introduced an error (as I now
see it)!  Users of that method now gets 0@0 instead of "the real cursor
position" (which I guess sort of "doesn't exist" when the screen is locked).
Sort of the same argument can be said of the "fix" to
TextTool>>displayText:at:  -  the invariant of updating "place" might be
broken (or is it? If the graphics returned an error code, did the
(underlying graphics) "place" update?).  It might be better to do "self
osNotification", but I am not sure about this - actually far from.  Does
anyone out there have any ideas or "gut feelings" about this?

One of the big problems with this (kind of) bug, is that it's next to
impossible to provoke.  After filing in the V352666w fix, most problems in
the development image went away.  And we have not been able to provoke these
errors in the production image.  The production image is served to our
customers as a Citrix Published Application.  Just starting the (test-)
application on a test server and locking the screen (or letting the
screen-saver do it) hasn't provoked the error so far.  One customer that has
problems with this error actually has a "company Citrix Desktop" that they
log on to that our "Citrix application" in turn is Published in to.
(Arrgh...)


Holm-Kjetil Holmsen
Senior Software Engineer
www.bluegarden.no


-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise
[mailto:[hidden email]] On Behalf Of Claus Kick
Sent: 2. mai 2011 12:40
To: [hidden email]
Subject: Re: Access is denied. (OS error 16r5)

Wasnt there an official "patch" for this?



--
Claus Kick

"Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf.
Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik.
Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie."

"If you are looking for me: I am somewhere near to lunacy.
More clearly, on the narrow path between lunacy and panic.
Right around the corner of  fear of death,
not far away from idiocy and insanity."

-----Ursprüngliche Nachricht-----
Von: "Kjell Harald Ulstad" <[hidden email]>
Gesendet: 29.04.2011 16:06:02
An: [hidden email]
Betreff: [VSWE-L] Access is denied. (OS error 16r5)


>Hi folks.
>
>Occasionally, we encounter the following error: Runtime error: Access
>is denied. (OS error 16r5).
>The error pop up when a Screensaver is running.
>Probably because VSE tries to write to the screen and Microsoft have
>changed the return value when a Screensaver is running ;-) The error
>log tells us that this has to do with GraphicsTool>>line:
>(and other places...)
>I've come up with a proposal for a solution (shown below the error log)
>but is it a better way to solve it?
>
>Error log:
>
>Runtime error: Access is denied. (OS error 16r5)
>
>Error(Exception)>>defaultAction
>Error(Exception)>>activateHandler: <anUndefinedObject>
>Error(Exception)>>handle Error(Exception)>>signal Error class(Exception
>class)>>signal: <'Access is denied. (O...'>
>Pen(Object)>>osError: <5>
>Pen(Object)>>osError
>[] in GraphicsTool>>line:
>Array(IndexedCollection)>>do: <aBlockClosure>
>Pen(GraphicsTool)>>line: <aPoint>
>Pen(GraphicsTool)>>lineFrom: <aPoint> to: <aPoint>
>Pen>>draw3DRect: <aRectangle> depth: <1> style: <#in>
>CX3DTextFrame>>displayWith: <aPen> inRect: <aRectangle>
>CX3DTextFrame(CPSubPane)>>displayWith: <aPen> inRect: <aRectangle>
>clipRect: <aRectangle>
>[] in CPSubPane>>display
>CX3DTextFrame(Window)>>doGraphics: <aBlockClosure>
>CX3DTextFrame(CPSubPane)>>display
>CX3DTextFrame(Window)>>display: <aRectangle>
>CX3DTextFrame(Window)>>wmPaint: <0> with: <0>
>NotificationManager>>notify: <aWinMessage> notifyRecursive
>NotificationManager>>recursiveMessage
>SystemDictionary>>recursiveMessage
>SystemDictionary>>launch
>NotificationManager>>readWinQueue
>NotificationManager>>runEventLoop
>Message>>perform
>Message>>evaluate
>Process>>safelyEvaluate: <aMessage>
>
>The cause seems to be '^self osError' and below is a proposal for a
>solution:
>
>line: aPoint
> "Private - Draw a line from the current location  to aPoint. Answer
>the new location."
>
> | anError |
> self allHandles
> do:
> [:h |
> (GDILibrary
>
>lineTo: h
>
>x: aPoint x
>
>y: aPoint y)
> ifFalse:
>
>[anError := KernelLibrary getLastError.
>
>(#(5) includes: anError) "Check for ERROR_ACCESS_DENIED"
>
>ifFalse: [^self osError].
>
>self osNotification]].
> ^location := aPoint rounded
>
>Original:
>line: aPoint
> "Private - Draw a line from the current location  to aPoint. Answer
>the new location."
> self allHandles do: [ :h |
> ( GDILibrary lineTo: h x: aPoint x y: aPoint y )
> ifFalse: [ ^self osError ] ].
> ^location := aPoint rounded
>
>Is this a good fix?
>Or shall I reimplement the osError on Pen or GraphicsTool and test
>there?
>
>We have already chanced three places where we call GDILibrary
> stretchBlt: destDC
> x: x1
> y: y1
> dWidth: dWidth
> dHeight: dHeight
> srcDC: srcDC
> xSrc: x2
> ySrc: y2
> sWidth: sWidth
> sHeight: sHeight
> rop: aRopConstant
>and just call "^self osNotification" instead of "^self osError " when
>stretchBlt... return false.
>
>And we can keep on changing one place after another, but I would like
>to "just fix it" :-)
>
>Regards
>
>/Kjell
>
>Kjell H. Ulstad
>Arkitekt. Systemeier Paga/R&D
>www.bluegarden.no
>
>*** this signature added by listserv ***
>*** Visit http://www.listserv.dfn.de/archives/vswe-l.html ***
>*** for archive browsing and VSWE-L membership management ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

 

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
Reply | Threaded
Open this post in threaded view
|

Float denormalized operand

Carl Gundel-3
In reply to this post by Kjell Harald Ulstad
For some reason VSE failed with a "Float denormalized operand" error
executing the following.

  Float fromInteger: 100

I can't reproduce it.  Why would it do this at all?  How would converting
100 to a float produce this error?

-Carl

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: Float denormalized operand

Andreas Rosenberg
Hi Carl,

this topic has been raised some time ago, if I remember correctly.

This is a bug in the VM, that will appear if any API call is doing floating
point operations.
I know this can happen with some printer drivers, so you will get "random"
errors after printing stuff.

During the API call, floating point instructions result in a
denormalized float (very small numbers - google it, if you want to know exactly how it works).
This status is signaled by setting a flag in the CPU floating point status word.
This flag stays until being cleared.
Usually the float status word should be cleared BEFORE doing any float operations
and should be checked AFTER any float operations.

The VSE VM does not clear this status word, but is checking for it.


Todor posted a workaround for this problem:

Float class>>fromInteger: anInteger
        "Answer a floating point representation
         of the argument anInteger."
    <primitive: 40>
    self clearExceptionFlags.
    ^self fromIntegerRetry: anInteger.

Float class>>fromIntegerRetry: anInteger
        "Answer a floating point representation
         of the argument anInteger."
    <primitive: 40>
    ^0.0 floatError

Similar implementations are needed for all kinds of float primitives,
if your app uses floats.


Regards

   Andreas

Andreas Rosenberg | eMail: [hidden email]
APIS GmbH         | Phone: +49 9482 9415-0
Im Haslet 42      | Fax: +49 9482 9415-55
93086 Worth/D     | WWW: <http://www.apis.de/>
Germany           | <http://www.fmea.de/>




-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise
[mailto:[hidden email]]On Behalf Of Carl Gundel
Sent: Montag, 16. Mai 2011 16:02
To: [hidden email]
Subject: Float denormalized operand


For some reason VSE failed with a "Float denormalized operand" error
executing the following.

  Float fromInteger: 100

I can't reproduce it.  Why would it do this at all?  How would converting
100 to a float produce this error?

-Carl

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: Float denormalized operand

Leandro Caniglia
In reply to this post by Carl Gundel-3
This is the code we have in that method.

Float class >> fromInteger: anInteger
<primitive: 40>
Float denormalizedOperandFlag ifTrue: [
Float clearExceptionFlags.
^self fromInteger: anInteger].
^0.0 floatError

/Leandro

On Mon, May 16, 2011 at 11:01 AM, Carl Gundel <[hidden email]> wrote:
For some reason VSE failed with a "Float denormalized operand" error
executing the following.

 Float fromInteger: 100

I can't reproduce it.  Why would it do this at all?  How would converting
100 to a float produce this error?

-Carl

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
Reply | Threaded
Open this post in threaded view
|

Re: Float denormalized operand

Leandro Caniglia
Just in case

Float class >> denormalizedOperandFlag
^(self status bitAnd: 2) ~= 0

On Mon, May 16, 2011 at 11:45 AM, Leandro Caniglia <[hidden email]> wrote:
This is the code we have in that method.

Float class >> fromInteger: anInteger
<primitive: 40>
Float denormalizedOperandFlag ifTrue: [
Float clearExceptionFlags.
^self fromInteger: anInteger].
^0.0 floatError

/Leandro


On Mon, May 16, 2011 at 11:01 AM, Carl Gundel <[hidden email]> wrote:
For some reason VSE failed with a "Float denormalized operand" error
executing the following.

 Float fromInteger: 100

I can't reproduce it.  Why would it do this at all?  How would converting
100 to a float produce this error?

-Carl

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***


*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
Reply | Threaded
Open this post in threaded view
|

Re: Float denormalized operand

Gerardo Richarte
In reply to this post by Carl Gundel-3
If you can't reproduce it anymore, it may be related to unclean float
flags left by previous operations.

    just a guess

On 05/16/2011 11:01 AM, Carl Gundel wrote:
> For some reason VSE failed with a "Float denormalized operand" error
> executing the following.
>
>   Float fromInteger: 100
>
> I can't reproduce it.  Why would it do this at all?  How would converting
> 100 to a float produce this error?

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: Float denormalized operand

Leandro Caniglia
That's precisely my guess. And that's why we changed the implementation of fromInteger:

/Leandro

On Mon, May 16, 2011 at 11:51 AM, Gerardo Richarte <[hidden email]> wrote:
If you can't reproduce it anymore, it may be related to unclean float
flags left by previous operations.

   just a guess

On 05/16/2011 11:01 AM, Carl Gundel wrote:
> For some reason VSE failed with a "Float denormalized operand" error
> executing the following.
>
>   Float fromInteger: 100
>
> I can't reproduce it.  Why would it do this at all?  How would converting
> 100 to a float produce this error?

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
Reply | Threaded
Open this post in threaded view
|

Re: Float denormalized operand

Todor Todorov
In reply to this post by Carl Gundel-3
Clear the float error flags. If I remember, some class method on Float.

This is due to 3rd party code not clearing the processor error flag registers after use.

-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Carl Gundel
Sent: 16. maj 2011 16:02
To: [hidden email]
Subject: Float denormalized operand

For some reason VSE failed with a "Float denormalized operand" error executing the following.

  Float fromInteger: 100

I can't reproduce it.  Why would it do this at all?  How would converting
100 to a float produce this error?

-Carl

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: Float denormalized operand

Lorin McCaffrey
In reply to this post by Carl Gundel-3
This has been discussed here a couple of years ago.  Below is the posting that helped us solve the problem in 2009 (thanks Todor!).  In our case, we traced the cause of the problem to a third party PDF tool we were using at the time... the tool seemed to sometime leave the register flag (discussed below) set at the end of an API call.  Sometime after that our Smalltalk image would give "Float denormalized operand" or "Float invalid operation".

From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Todor Todorov
Sent: Monday, April 27, 2009 7:32 AM
To: [hidden email]
Subject: Re: impossible Error (Float invalid operation)

There is a bug in VSE. VSE uses some CPU primitive for this, which if it fails generates an exception. This on the CPU level is done by setting a register flag to tell your app (VSE) that the CPU instruction failed / overflowed. However, it's your responsibility to clear the flag before calling the to-float function. If somebody else did float conversion that failed and didn't clear the flag, you will see those strange results.

Here's our solution. Try, if failed, clear the flag and retry.

Float class>>fromInteger: anInteger
        "Answer a floating point representation
         of the argument anInteger."
    <primitive: 40>
    self clearExceptionFlags.
    ^self fromIntegerRetry: anInteger.

Float class>>fromIntegerRetry: anInteger
        "Answer a floating point representation
         of the argument anInteger."
    <primitive: 40>
    ^0.0 floatError



-----Original Message-----
From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Carl Gundel
Sent: Monday, 16 May, 2011 8:02 AM
To: [hidden email]
Subject: Float denormalized operand

For some reason VSE failed with a "Float denormalized operand" error
executing the following.

  Float fromInteger: 100

I can't reproduce it.  Why would it do this at all?  How would converting
100 to a float produce this error?

-Carl

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***
Reply | Threaded
Open this post in threaded view
|

Re: Float denormalized operand

Carl Gundel-3
In reply to this post by Leandro Caniglia

Thanks for all the feedback.  Very helpful.  :-)

 

-Carl

 

From: Using Visual Smalltalk for Windows/Enterprise [mailto:[hidden email]] On Behalf Of Leandro Caniglia
Sent: Monday, May 16, 2011 11:13 AM
To: [hidden email]
Subject: Re: Float denormalized operand

 

That's precisely my guess. And that's why we changed the implementation of fromInteger:

 

/Leandro

On Mon, May 16, 2011 at 11:51 AM, Gerardo Richarte <[hidden email]> wrote:

If you can't reproduce it anymore, it may be related to unclean float
flags left by previous operations.

   just a guess


On 05/16/2011 11:01 AM, Carl Gundel wrote:
> For some reason VSE failed with a "Float denormalized operand" error
> executing the following.
>
>   Float fromInteger: 100
>
> I can't reproduce it.  Why would it do this at all?  How would converting
> 100 to a float produce this error?

***           this signature added by listserv             ***
*** Visit  http://www.listserv.dfn.de/archives/vswe-l.html ***
*** for archive browsing and VSWE-L membership management  ***

 

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
Reply | Threaded
Open this post in threaded view
|

TabControls and image exiting

Carl Gundel-3
In reply to this post by Leandro Caniglia

Now and then VSE will crash without error (just go away) when interacting with tab controls.  I used to think the problem was related to the use of RichEdit controls in a tabbed UI, but now it has also happened in tabbed UIs that have other controls in them.  This isn’t reproducible easily, but sometimes while using the mouse to switch from one tab to another the app will “just go away”.

 

I also wonder  if it’s the tooltip code that might be causing the problem.

 

Anyone else experience this?  Thanks.

 

-Carl

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***
12