Bitblt>>copyBits

Hello,
i'd like to mark code, located in Bitblt>>copyBits as buggy,
regardless that it's currently working.
A simple reason: if there is no such primitive, or primitive
constantly fails, then code, located in method's body leading to
infinite recursion.
I consider this as a major bug, especially in such critical place,
where correct behavior is at utmost importance.

A simple replacement of #copyBits to #copyBitsAgain in method should
prevent further recursion caused by primitive failure.


--
Best regards,
Igor Stasenko AKA sig.

On Feb 20, 2008, at 16:48 , Igor Stasenko wrote:

> Hello,
> i'd like to mark code, located in Bitblt>>copyBits as buggy,
> regardless that it's currently working.
> A simple reason: if there is no such primitive, or primitive
> constantly fails, then code, located in method's body leading to
> infinite recursion.
> I consider this as a major bug, especially in such critical place,
> where correct behavior is at utmost importance.

Firstly, copyBits is a non-optional primitive, so it should not fail  
constantly.

Secondly, which case in the body leads to direct recursion? At a  
quick glance they seem fine.

- Bert -

On 20/02/2008, Bert Freudenberg <[hidden email]> wrote:
You right, but it _is_ optional, on HydraVM :)
Consider my reasoning, why i think it's a bug:
- there is virtually impossible to strip image to prevent it from
using BitBlt/morphic.
Which means, that the only way left is to make primitives fail.
And now we got a problem: there is a code in image which thinks that
primitive can't constantly fail.
Maybe i'm biased but i don't like the code, which is too optimistic
about why primitive failed.

>
>  Secondly, which case in the body leads to direct recursion? At a
>  quick glance they seem fine.
>

I don't have a stack dump atm. Need to find it in my mail.

Another issue, which i found just today and like to be discussed is
Behavior>>basicNew: failure handling.

It is caused by a bug in ioScreenSize() vm function which returns a
size of enormous dimentions (59999 x 24555) . And VM simply refuses to
allocate bitmap of such size.

Here is the failure handling code:

        self isVariable ifFalse:
                [self error: self printString, ' cannot have variable sized instances'].
        (sizeRequested isInteger and: [sizeRequested >= 0]) ifTrue:
                ["arg okay; space must be low."
                self environment signalLowSpace.
                ^ self basicNew: sizeRequested  "retry if user proceeds"].
        self primitiveFailed

Since sizeRequested is integer and size requested is obviously > 0, it
enters the case
                self environment signalLowSpace.
                ^ self basicNew: sizeRequested

I think it's a little brittle code.
IMHO 'self environment signalLowSpace' should block until user decides
what to do with given problem: abandon process or proceed.

In current implementation it looks like given code relies too much on
scheduler behavior: it expecting that by signaling low space semaphore
current process will be interrupted by higher priority process
immediately.

Or, if there was intent to inform user about low space, while
continuing running, in case, where primitive fails constantly, again
leading to infinite recursion.
In this case, i suppose, primitive should be invoked only once and if
it failed again, stop with error, and don't try torture VM/stack :)


--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko wrote:
> Another issue, which i found just today and like to be discussed is
> Behavior>>basicNew: failure handling.

There is a fix in Croquet (update your image from the repository at
http://jabberwocky.croquetproject.org:8889/Homebase.html) by raising an
OutOfMemory error which is something that can be handled by your code
whereas the environmental lowspace signal cannot. We ran into this
problem when our servers got hit with malformed requests and an attempt
to allocate a huge amount of memory sent the image spinning into an
infinite loop of depth.

Cheers,
   - Andreas

On 20/02/2008, Andreas Raab <[hidden email]> wrote:
Thanks for advice. Btw, do you plan to make this patch available for
other images (not only Croquet), or it's already made, and i'm missed
it?

>  Cheers,
>
>    - Andreas
>
>


--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko wrote:
> Thanks for advice. Btw, do you plan to make this patch available for
> other images (not only Croquet), or it's already made, and i'm missed
> it?

This fix has been available in the Croquet repository for a while.
Contrary to some of the other things that I've openly advocated I don't
consider this a mission critical bug for most people so I haven't
advertised it here. If you want to do this, be my guest ;-) BTW, there
are some other fixes that we've pushed to Croquet, see:

https://lists.duke.edu/sympa/arc/croquet-dev/2007-05/msg00035.html

Cheers,
   - Andreas

Hi Igor--

 > there is virtually impossible to strip image to prevent it from
 > using BitBlt/morphic.

      I've done it, it's actually not that hard.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

On 20/02/2008, Craig Latta <[hidden email]> wrote:
Using automated process, and by taking any image?
In HydraVM package I've done a small script which simply prepares
image to run as secondary. It's not stripping Morphic code or
whatsoever, it just stops UI process and prevents it from running at
image startup and in case of errors.
But there can be any code in any random package which can use UI.  I
simply can't prevent from using UI in all places.

Yes, if people can spend time to strip image of morphic code, then
obviously it's not a problem at all.
But i'm not sure it should be my concern to provide such images.
HydraVM is VM for generic purpose at the end.

--
Best regards,
Igor Stasenko AKA sig.

Hi Andreas,

Is there any chance to get a change set for those fixes? Many
(especially System, Kernel, VMMaker and Collection) would be useful for
my Morphic3 image.

Cheers,
Juan Vuletich

Andreas Raab wrote:

Juan Vuletich wrote:
> Is there any chance to get a change set for those fixes? Many
> (especially System, Kernel, VMMaker and Collection) would be useful for
> my Morphic3 image.

If there is a way of getting a change set from Monticello you can just
download the Hedgehog release and point it to the jabberwocky
repository. Other than that I don't have change sets.

Cheers,
   - Andreas

 > > > there is virtually impossible to strip image to prevent it from
 > > > using BitBlt/morphic.
 > >
 > > I've done it, it's actually not that hard.
 >
 > Using automated process, and by taking any image?

      Yes and yes. I load code into the subject image for remote
messaging, and use a VM which keeps track of which methods have been
run, and with a garbage collector that doesn't mark methods which
haven't been run. From a remote image, I invoke the GC in the subject
image and all but about 300k of it falls away in one fell swoop.

      Also see
http://lists.squeakfoundation.org/pipermail/spoon/2006-February/000105.html


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

On 21/02/2008, Craig Latta <[hidden email]> wrote:
Yes, i know this. But to determine what is garbage and what is not it
requires running some code, and this, in own turn means some user
involvement.
Please, don't take me wrong, i very like this feature of Spoon and it
would be good to integrate it into HydraVM, so you don't need to run
code via simulator, and will be allowed to run it in already started,
live image and then do GC.
And by guessing your next statement about simulator :) : yes, in
future,  VM code should be refactored to run with simulator.


>       Also see
>  http://lists.squeakfoundation.org/pipermail/spoon/2006-February/000105.html
>
>

--
Best regards,
Igor Stasenko AKA sig.

 > But to determine what is garbage and what is not it requires running
 > some code, and this, in own turn means some user involvement.

      No, it doesn't. This is all done programmatically from the
controlling image, using remote messaging.

 > ...it would be good to integrate it into HydraVM, so you don't need to
 > run code via simulator, and will be allowed to run it in already
 > started, live image and then do GC.

      This is already exactly how I do it. The simulator is not involved
in any way.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]