David,

incidentally I've taken a look into the Squeak ML (not active here for a
very long time) and seen your bug report: for obvious reasons I don't
like bugs in the LargeIntegers plugin!

In an older one nothing crashes (but see below):

Smalltalk vmVersion 'Squeak3.6 of ''6 October 2003'' [latest update: #5429]'

Smalltalk listLoadedModules #('SoundPlugin 1 April 2004 (i)'
'SocketPlugin 1 April 2004 (i)' 'LargeIntegers v1.2 1 April 2004 (i)'
'B2DPlugin 1 April 2004 (i)' 'FloatArrayPlugin 1 April 2004 (i)'
'Matrix2x3Plugin 1 April 2004 (i)' 'BitBltPlugin 1 April 2004 (i)'
'SecurityPlugin 1 April 2004 (i)' 'FilePlugin 1 April 2004 (i)'
'MiscPrimitivePlugin 1 April 2004 (i)')

Integer new: 4 neg: false 0000

| li |
li _ Integer new: 4 neg: false.
{ li - 0. li + 0. li + 1. li - 1. li - 2. li - 1 + 1.
(li - 1 + 1) storeStringBase: 16.
(li - 1 + 1) = 16r100000000.
(li - 1 + 1) = (2 raisedTo: 32).
li normalize.
li.
li printString.
}
 #(0 0 1 4294967295 4294967294 4294967296 '16r100000000' true true 0
0000 '0000')

My VM stems from a Debian package from Ian (not self compiled).


After some playing around I've found a possibility to crash my VM, with:
  (SmallInteger maxVal + 1) quo: (Integer new: 4 neg: false)
.
This should be changed.
The problem is that in LargeIntegersPlugin>>primDigitDiv:negative: there
is only a division by zero check for a normalized zero (SmallInteger 0)
and *not* for an unnormalized LargeInteger zero (LargeInteger with zero
bytes). This is the same as in the calling method
Integer>>digitDiv:neg:, but in contrast to Smalltalk where this is
"just" a violation of the method precondition made by the caller
(leading to undefined behavior) such a wrong arg leads to a crash in the
plugin...
I admit, that crashing the VM is untolerable behavior, please give me
some time for suppliying a fix.

Beside this problem there shouldn't reside unnormalized LargeIntegers in
the image, except as intermediate results of numeric computations.


Greetings,
Stephan


David T. Lewis wrote:
> On Sat, May 22, 2004 at 08:34:31AM -0700, Tim Rowledge wrote:
> 
>>"David T. Lewis" <lewis at mail.msen.com> wrote:
>>
>>
>>>A certain non-normalized instance of PositiveLargeInteger in the image crashes
>>>the VM with a segmentation fault.
>>
>>[snip]
>>
>>>  This will be a LargePositiveInteger. It was element 33 in the array in my test.
>>>
>>
>>I'm pretty sure that this is the LPI in the specialObjectsArray. Never
>>quite understood what it was there for.  Just blew away my image trying
>>to find it...
> 
> 
> Hmm, try inspecting "Integer new: 4 neg: false". This will allow you blow
> your image away with considerably less effort. Integer>>new:neg: is used
> only by private methods, but is not itself labeled as private.
> 
> Perhaps this is not a pathological instance after all, just one that is
> not likely to be encountered in common usage. In any case, both the large
> integer plugin and the Integer>>digitDev:neg: method have trouble digesting
> this particular critter.
> 
> Dave
> 
> 
> 

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3