I am getting this when trying to open a SqueakMap Package Loader in a fresh 3.7-5989-Full image. I am sure that I could do this before, has anything changed on the SqueakMap side?
I am on x86 Linux (Ubuntu) with the 3.6-3 VM from Ian Piumarta's site.
Thanks in advance for any help,
Barry
1 January 2005 3:38:11 pm
VM: unix - a SmalltalkImage Image: Squeak3.7 [latest update: #5989]
SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /home/barry/Squeak/work/test Trusted Dir /home/barry/Squeak/work/test/secure Untrusted Dir /home/barry/Squeak/work/test/untrusted
UndefinedObject(Object)>>doesNotUnderstand: #do: Receiver: nil Arguments and temporary variables: aMessage: do: [] in ImageSegment>>comeFullyUpOnReload: {[:importedObject | (im...etc... Receiver's instance variables: nil
ImageSegment>>comeFullyUpOnReload: Receiver: an ImageSegment Arguments and temporary variables: smartRefStream: a SmartRefStream a ByteArray(39 70 114 111 109 32 83 113 117 10...etc... mapFakeClassesToReal: an IdentityDictionary(Fake37SMSqueakMap->SMSqueakMap ) ccFixups: true receiverClasses: an IdentitySet() rootsToUnhiberhate: nil myProject: nil importedObject: nil aFake: nil Receiver's instance variables: arrayOfRoots: nil segment: a WordArrayForSegment(1929386342 218247691 2180484332 2182593837 31614...etc... outPointers: #(Fake37SMSqueakMap nil 'sm' true Dictionary SMFileCache Array UUI...etc... state: #imported segmentName: nil fileName: nil endMarker: a ByteArray(102 25 0 115 11 50 2 13 20 0 0 0 5 0 0 128 73 1 216 18 8...etc... userRootCnt: 1 renamedClasses: nil
SmartRefStream(DataStream)>>next Receiver: a SmartRefStream a ByteArray(39 70 114 111 109 32 83 113 117 101 97 107 51 46 54 32 111 10...etc... Arguments and temporary variables: type: 16 selector: #readShortInst anObject: an ImageSegment isARefType: true pos: nil internalObject: nil Receiver's instance variables: byteStream: a RWBinaryOrTextStream a ByteArray(39 70 114 111 109 32 83 113 117 ...etc... topCall: #marked basePos: 153 references: an IdentityDictionary() objects: an IdentityDictionary(5->#('class structure' a Dictionary(#Array->#(0)...etc... currentReference: 2778 fwdRefEnds: an IdentityDictionary() blockers: an IdentityDictionary() skipping: an IdentitySet() insideASegment: false structures: a Dictionary(#Array->#(0) #ArrayedCollection->#(0) #ByteArray->#(0)...etc... steady: a Set(Integer UUID SMDocument Symbol SMCategorizableObject String SMFil...etc... reshaped: nil renamed: a Dictionary(#FlasherMorph->#Flasher ) renamedConv: a Dictionary(1->#SMSqueakMap 5->#Dictionary 6->#SMFileCache 7->#Ar...etc... superclasses: a Dictionary(#Array->#ArrayedCollection #ArrayedCollection->#Sequ...etc... progressBar: nil objCount: nil classInstVars: nil
SmartRefStream(ReferenceStream)>>next Receiver: a SmartRefStream a ByteArray(39 70 114 111 109 32 83 113 117 101 97 107 51 46 54 32 111 10...etc... Arguments and temporary variables: curPosn: 2778 skipToPosn: nil haveIt: false theObject: false wasSkipping: nil Receiver's instance variables: byteStream: a RWBinaryOrTextStream a ByteArray(39 70 114 111 109 32 83 113 117 ...etc... topCall: #marked basePos: 153 references: an IdentityDictionary() objects: an IdentityDictionary(5->#('class structure' a Dictionary(#Array->#(0)...etc... currentReference: 2778 fwdRefEnds: an IdentityDictionary() blockers: an IdentityDictionary() skipping: an IdentitySet() insideASegment: false structures: a Dictionary(#Array->#(0) #ArrayedCollection->#(0) #ByteArray->#(0)...etc... steady: a Set(Integer UUID SMDocument Symbol SMCategorizableObject String SMFil...etc... reshaped: nil renamed: a Dictionary(#FlasherMorph->#Flasher ) renamedConv: a Dictionary(1->#SMSqueakMap 5->#Dictionary 6->#SMFileCache 7->#Ar...etc... superclasses: a Dictionary(#Array->#ArrayedCollection #ArrayedCollection->#Sequ...etc... progressBar: nil objCount: nil classInstVars: nil
--- The full stack --- UndefinedObject(Object)>>doesNotUnderstand: #do: ImageSegment>>comeFullyUpOnReload: SmartRefStream(DataStream)>>next SmartRefStream(ReferenceStream)>>next - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SmartRefStream>>next SmartRefStream>>scanFrom: ObjectScanner>>scanFrom: [] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: {[val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self nextChunk l...]} ...etc...
On Sat, 01 Jan 2005 15:50:13 +0000, Barry Bridgens barry@bridgens.me.uk wrote:
I am getting this when trying to open a SqueakMap Package Loader in a fresh 3.7-5989-Full image. I am sure that I could do this before, has anything changed on the SqueakMap side?
I am on x86 Linux (Ubuntu) with the 3.6-3 VM from Ian Piumarta's site.
I posted a similar error before. Not sure if it is related, but I had been using the 3.6 VM with a 3.7 image. When I switched to the 3.7 VM (windows), the problem seem to go away.
"Yar Hwee Boon" hboon@motionobj.com wrote:
I posted a similar error before. Not sure if it is related, but I had been using the 3.6 VM with a 3.7 image. When I switched to the 3.7 VM (windows), the problem seem to go away.
It is absolutely related. It's nothing to do with particular VMs as such, nor cpu architecture (well....) but all to do with the OS and it's approach to allocating memory.
If the chunk allocated for Object Space end above 2Gb then plausible OOPS will appear to be negative numbers when treated as ints. The VM code uses ints all over the place - as it has for eight plus years now - and unless you have some bizarre cpu/compiler combination the comparison of two OOPS may well go wrong. It is a strange coincidence that the only place where this appears to have an effect is in a routine involved in loading and image segment.
We _will_ fix it sometime. Just not today. If I were being paid to work on such issues it would have been fixed already but I'm currently occupied with other issues and so it has to sit on my todo list.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim The steady state of disks is full. - Ken Thompson
On Sat, 01 Jan 2005 20:21:47 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
"Yar Hwee Boon" hboon@motionobj.com wrote:
I posted a similar error before. Not sure if it is related, but I had been using the 3.6 VM with a 3.7 image. When I switched to the 3.7 VM (windows), the problem seem to go away.
It is absolutely related. It's nothing to do with particular VMs as such, nor cpu architecture (well....) but all to do with the OS and it's approach to allocating memory.
Just to clarify - do you mean that the switch to a 3.7 VM should not be the reason that the problem goes away?
squeak-dev@lists.squeakfoundation.org