It happened to me a couple of time when editing methods in the senders/implementors. I never found out why Ben On May 25, 2012, at 10:12 AM, Tudor Girba wrote:

The problem is also reproducible with the latest Nautilus 1.4 image.

Doru

On 25 May 2012, at 09:57, Fabrizio Perin wrote:

...

Hi, I'm using last Moose build on top of CogVM 2550 and each time I click on a method an error pops up (see the attachment). The same problem I have it with older builds of Moose but I don't have any problem if I open the same image with Cog VM 2540 or CogVM from the Pharo web site.

I'm on Mac os 10.7.4 and the image is:

Pharo1.4 Latest update: #14438

Cheers, Fabrizio

<MooseAnd2550Error.tiff>

-- www.tudorgirba.com

"Every successful trip needs a suitable vehicle."

On 25 May 2012 20:39, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Fri, May 25, 2012 at 12:57 AM, Fabrizio Perin <fabrizio.perin@gmail.com> wrote:

...

Hi, I'm using last Moose build on top of CogVM 2550 and each time I click on a method an error pops up (see the attachment). The same problem I have it with older builds of Moose but I don't have any problem if I open the same image with Cog VM 2540 or CogVM from the Pharo web site.

I changed the definition of at: for CompiledMethod to prevent it accessing bytes outside of the bytecodes part of a compiled method.  What's happening here is that a hash is being derived form the compiled method by looking at the pointers part of the compiled method (i.e. bytes < aMethod initialPC).

Yes, this is reasonable. But the more cases like this we find, the more i feel that we need better format for compiled methods, to keep its bytecode in a separate plain bytearray, to be able to reshape/modify the method's state and access it in convenient manner. A bytecode could be held in a first ivar of compiled method. Yes, we will have 4-8 more bytes per method in image (a ByteArray instance header).. but at the same time, we can save our brain cells as well as save bytes of implementation in both image and vm sides: - no need to deduce initialPc/end pc , because it is always 1...bytearray size - simpler method header (no need to count method's literals) - no need for a method trailer crap, any additional state can be held in own ivar. - we can simplify implementation - free the placeholders in object format for something else, now 12..15 (4 values) is for CompiledMethod, we may need only 1. - i would even make an extra slot for JIT code pointer, instead of insane hacks which Eliot has to introduce in Cog, just because of need to keep things compatible. And more about space. My image is 43Mb now. CompiledMethod allInstances size 63563 so, if we have 4 more bytes per method .. this is 254252 more bytes. which is 0.5 % of total space. 8 more bytes per method.. 1% so my image will be 1% bigger.. we dooommeeed..

 But it is wrong to try and derive a hash from these bytes.  Since the GC can move objects these bytes can change as the GC moves the literals a method references (unlike the bytes between: aMethod initialPC and: aMethod size).

Yes. Strange that nobody noticed this before, perhaps because nobody places methods in dicts/setc :) I never found why one would want to put methods in dictionary (they are naturally found in dictionary already). But in case of Moose, this is of course possible. More than that, since CompiledMethod redefines #=, it is strange that it's not redefines #hash as well, because it is one of requirements to make sure they are always in sync.

Two conclusions:

The solution is to define CompiledMethod>hash such that it does not access bytes < initialPC.  The hash it is inheriting from ByteArray is fine for ByteArray but not at all OK for CompiledMethod.

Yes, i would just do self methodClass hash bitXor: self selector hash

The VM is revealing a latent bug, i.e. that on older VMs the system could be computing a variable hash, and hence result in not-found errors in certain circumstances, hence the VM is right to impose this stricter bounds checking.

...

I'm on Mac os 10.7.4 and the image is:

Pharo1.4 Latest update: #14438

Cheers, Fabrizio

-- best, Eliot

-- Best regards, Igor Stasenko.