Array new: SmallInteger maxVal

[Torsten Bergmann]

 
VisualWorks throws an exception "Size exceeds implementation limit of 2^28 elements".

Pharo and Squeak also crash the VM when you evaluate:

   (Array new: SmallInteger maxVal) last

What is interesting is that when you doIt in Squeak trunk:  

(Array new: SmallInteger maxVal) last

nothing happens, but VM crashes when you printIt

In Pharo VM already crashes when you just doIt.

It crashes in both when you inspectIt.
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

[Michael van der Gulik-2]

 

On Wed, Oct 7, 2009 at 9:17 PM, Torsten Bergmann <[hidden email]> wrote:

VisualWorks throws an exception "Size exceeds implementation limit of 2^28 elements".

Pharo and Squeak also crash the VM when you evaluate:

  (Array new: SmallInteger maxVal) last

What is interesting is that when you doIt in Squeak trunk:

(Array new: SmallInteger maxVal) last

nothing happens, but VM crashes when you printIt

In Pharo VM already crashes when you just doIt.

It crashes in both when you inspectIt.

...should this be fixed in the image or the VM?

Is it the responsibility of the image to make sure that the VM isn't passed insane values, or is the responsibility of the VM to not crash when the image asks for insane values.

Gulik.

--
http://gulik.pbwiki.com/

[Bert Freudenberg]

Some javascript/style in this post has been disabled (why?)

 

On 07.10.2009, at 22:37, Michael van der Gulik wrote:

On Wed, Oct 7, 2009 at 9:17 PM, Torsten Bergmann <[hidden email]> wrote:

VisualWorks throws an exception "Size exceeds implementation limit of 2^28 elements".

Pharo and Squeak also crash the VM when you evaluate:

  (Array new: SmallInteger maxVal) last

What is interesting is that when you doIt in Squeak trunk:

(Array new: SmallInteger maxVal) last

nothing happens, but VM crashes when you printIt

In Pharo VM already crashes when you just doIt.

It crashes in both when you inspectIt.

...should this be fixed in the image or the VM?

Is it the responsibility of the image to make sure that the VM isn't passed insane values, or is the responsibility of the VM to not crash when the image asks for insane values.

The latter.

- Bert -

[John M McIntosh]

 
It's a issue of what is insane, plus adding boundary checks everywhere  
that is rarely needed.

The correct response for the issue is to throw a out of memory  
exception when the VM figures out it
can't allocate the 4GB of memory here.

I a quick check shows the primitive fails, then the image side  
primitive failure code does the wrong thing...

In this case I get a MethodContext claiming to be  
"RunArray>>copyFrom:to:"
which if you attempt to work further with, causes problems.

On 2009-10-07, at 1:37 PM, Michael van der Gulik wrote:

>
>
> On Wed, Oct 7, 2009 at 9:17 PM, Torsten Bergmann <[hidden email]>  
> wrote:
>
> VisualWorks throws an exception "Size exceeds implementation limit  
> of 2^28 elements".
>
> Pharo and Squeak also crash the VM when you evaluate:
>
>   (Array new: SmallInteger maxVal) last
>
> What is interesting is that when you doIt in Squeak trunk:
>
> (Array new: SmallInteger maxVal) last
>
> nothing happens, but VM crashes when you printIt
>
> In Pharo VM already crashes when you just doIt.
>
> It crashes in both when you inspectIt.
>
>
> ...should this be fixed in the image or the VM?
>
> Is it the responsibility of the image to make sure that the VM isn't  
> passed insane values, or is the responsibility of the VM to not  
> crash when the image asks for insane values.
>
> Gulik.
>
>
>
> --
> http://gulik.pbwiki.com/

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================

[Douglas Brebner]

 
John M McIntosh wrote:
>
> It's a issue of what is insane, plus adding boundary checks everywhere
> that is rarely needed.
>
> The correct response for the issue is to throw a out of memory
> exception when the VM figures out it
> can't allocate the 4GB of memory here.
>

Isn't that possible on a 64bit vm/image?

[Bert Freudenberg]

 

On 08.10.2009, at 10:43, Douglas Brebner wrote:

>
> John M McIntosh wrote:
>>
>> It's a issue of what is insane, plus adding boundary checks  
>> everywhere
>> that is rarely needed.
>>
>> The correct response for the issue is to throw a out of memory
>> exception when the VM figures out it
>> can't allocate the 4GB of memory here.
>>
>
> Isn't that possible on a 64bit vm/image?

http://squeakvm.org/squeak64/faq.html

- Bert -

[David T. Lewis]

 
On Thu, Oct 08, 2009 at 09:43:34AM +0100, Douglas Brebner wrote:

>  
> John M McIntosh wrote:
> >
> > It's a issue of what is insane, plus adding boundary checks everywhere
> > that is rarely needed.
> >
> > The correct response for the issue is to throw a out of memory
> > exception when the VM figures out it
> > can't allocate the 4GB of memory here.
> >
>
> Isn't that possible on a 64bit vm/image?

Well, there are definitely bugs in the VM right now and these need to be
fixed. But as a practical matter I find that the following takes several
minutes to complete on my computer:

        Array new: 16r001FFFFFF

This is well within the addressing range for both 32-bit images and
32-bit VMs, so as a practical matter 64-bit addressing does not matter
here.

So in summary:

- The VM needs to be fixed to behave properly even if the amount of
memory requested is unreasonable.

- It might be useful to have the image guard against requests that
are unreasonable (e.g. raise an error instead of calling a primitive
that is going to take several minutes to complete).

The first point is indisputable, the second could probably be debated
for a long time ;)

Dave