[BUG] Pathological LargePositiveInteger instance discovered in the wild

David T. Lewis lewis at mail.msen.com
Sat May 22 15:20:12 UTC 2004


A certain non-normalized instance of PositiveLargeInteger in the image crashes
the VM with a segmentation fault.

The instance of PositiveLargeInteger that I found cannot be directly inspected
(VM crashes when inspecting it), but it has the following characteristics:

badLargeInteger - 0 ==> 0
badLargeInteger + 0 ==> 0
badLargeInteger + 1 ==> 1
badLargeInteger - 1 ==> 4294967295
badLargeInteger - 2 ==> 4294967294
badLargeInteger - 1 + 1 ==> 4294967296
(badLargeInteger - 1 + 1) storeStringBase: 16 ==> '16r100000000'
(badLargeInteger - 1 + 1) = 16r100000000 ==> true
(badLargeInteger - 1 + 1) = (2 raisedTo: 32) ==> true
badLargeInteger normalize ==> 0
badLargeInteger == > KABOOM
badLargeInteger printString ==> KABOOM

Working from a debugger, the closest I can get the the crash is:
badLargeInteger digitDiv: 10 neg: false ==> KABOOM

This is calling Integer>>digitDiv:neg: which calls primDigitDivNegative in
the LargeIntegers plugin. Disabling the plugin prevents the VM crash, but
badLargeInteger still cannot be inspected because the #digitDev:neg method
fails.

>From the debugger (with the plugin disabled) I can see that the four byte
slots in badInteger are all zero (despite the '16r100000000' interpretation
above), so I am inclined to think that this is an "impossible" instance of
LargePositiveInteger, and fixing the plugin and/or #digitDiv:neg: method
would just be masking the real problem somewhere else.

Having said that, I have no idea where the underlying problem might lie,
so I'm just posting this as a BUG report with no fix proposed.

The problem can be reproduced as follows:

Test system:
  Smalltalk vmVersion ==> 'Squeak3.7beta of ''1 April 2004'' [latest update: #5868]'
  Smalltalk osVersion ==> 'linux-gnu'

- Open a new process browser.
- Select the low space watcher process.
- Explore context (right pane option).
- In the explorer, select the semaphore.
- Find objects point to the semaphore.
- You should see a three element array.
- Save your image.
- Select element 1, an Association (no problem).
- Select element 3, a Process (no problem).
- Select element 2, a Array ==> KABOOM.
- Restart the image, and from the inspector on the three-element array,
  open an inspector on element 2 (inspect "self at: 2").
- Save your image.
- Inspect the elements of the array until you find the one that crashes the VM.
  This will be a LargePositiveInteger. It was element 33 in the array in my test.


Here is the console (stderr) output when the VM crashes:

lewis at dtlewis:~/squeak/squeak3.7> squeak -memory 10m BFAV

Segmentation fault

1106979208 Integer>quo:
1106979116 LargePositiveInteger>quo:
1106979008 Integer>printOn:base:
1106978916 Number>printOn:
1106979848 [] in Object>printStringLimitedTo:
1106978824 SequenceableCollection class>streamContents:limitedTo:
1106978732 Object>printStringLimitedTo:
1106979572 [] in MethodContext>printDetails:
1106978596 BlockContext>on:do:
1106978412 BlockContext>ifError:
1106975848 MethodContext>printDetails:
1106963652 ContextPart>errorReportOn:
1106958108 SystemDictionary>logError:inContext:to:
1106744736 [] in Debugger class>openOn:context:label:contents:fullView:
1106744644 BlockContext>on:do:
1106744268 [] in Debugger class>openOn:context:label:contents:fullView:
1106744520 [] in BlockContext>newProcess
Aborted




More information about the Squeak-dev mailing list