Don't know whether it's related or not, but just the other day I was updating builderCI to use the zeroconf scripts for Pharo1.2 through Pharo1.4 when I hit a problem loading a package from smalltalkhub that only failed (consistently) for Pharo1.3[1] and when I reverted to using the relatively old vm built into builderCI the loading problem disappeared[2] ... and I concluded that there was something in Pharo-3.0 that did not play well with the recent vm(only as Pharo-1.2 and Pharo-1.4 seemed to work fine).

The old vm suits my purposes just fine, but I would agree that there is something fishy there related to the vms ...

Dale

[1]��https://travis-ci.org/dalehenrich/builderCI/jobs/38547637#L334

[2]��https://travis-ci.org/dalehenrich/builderCI/builds/38551292

On Fri, Oct 24, 2014 at 7:29 AM, Max Leske <maxleske@gmail.com> wrote:

Hi

I have a rather strange problem with rehasing that occurred simultaneously multiple times on the same day but not since. Luckily I��ve saved an image with the debugger in it. The mean thing is: that doesn��t help me at all because from what I can tell either the Debugger is broken or there��s a VM problem.

Note:
The image is a Pharo 1.3 image. The problem occurred on two different VMs independently, an NBCog VM (Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-EstebanLorenzano.166] 21.0) and a Squeak VM (Squeak3.10.2 of '5 June 2008' [latest update: #7179]).
The operation during which this happened was the loading of an ImageSegment (in both instances).

Here��s what happened. I got a SubscriptOutOfBounds error during rehashing of a Dictionary. When I look at the debugger it��s clear why the exception got signaled but not how that situation could ever happen.

These are the top three contexts on the stack:

Array(Object)>>errorSubscriptBounds:
Array(Object)>>at:put:
CBConfiguration(Dictionary)>>noCheckAdd:

This is the #noCheckAdd: method��

noCheckAdd: anObject
�� "Must be defined separately for Dictionary because (self findElementOrNil:) expects a key, not an association.�� 9/7/96 tk"

�� array at: (self findElementOrNil: anObject key) put: anObject.
�� tally := tally + 1

and here��s #at:put: where the exception is signaled:

at: index put: value
�� <primitive: 61>
�� index isInteger ifTrue:
�� [self class isVariable
�� ifTrue: [(index >= 1 and: [index <= self size])
�� ifTrue: [self errorImproperStore]
�� ifFalse: [self errorSubscriptBounds: index]] <�� signaled
�� ifFalse: [self errorNotIndexable]].
�� index isNumber
�� ifTrue: [^self at: index asInteger put: value]
�� ifFalse: [self errorNonIntegerIndex]

Here��s the weird thing: according to the debugger ��array' in #noCheckAdd: IS NOT THE SAME INSTANCE as ��self�� in #at:put:!!!!!! ????????? When I look at the pointers to both arrays, the correct one is pointed to by the dictionary while the other is only being referenced by the exception context:

Bad array:
1: SubscriptOutOfBounds: 88
2: Array(Object)>>errorSubscriptBounds:
3: Array(Object>>at:put:
4: an Inspector
��

Good array:
1: aCBConfiguration(size 107)

I really have no clue how this could have happened. I��d appreciate any thoughts you might have��

Cheers,
Max