I have already opened an issue several months ago: http://code.google.com/p/pharo/issues/detail?id=5005 I have also made it as much reproducable as I could and I have also asked for help: http://forum.world.st/Help-with-cleanUpForRelease-is-broken-MessageNotUnders... No answers :( Cheers On Tue, Jan 17, 2012 at 10:18 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:

Hi Yanni

open a bug entry. We got some strange behavior with becomeForward: and set rehash and I wonder if this is not related.

stef

On Jan 17, 2012, at 10:03 PM, Yanni Chiu wrote:

...

Using Pharo 1.4 (#220), I end up in: ByteSymbol(Object)>>doesNotUnderstand: #run:with:in:

which was called from: (MCPackage named: self theScriptLoaderPackageName) unload.

First I thought it was because I had OSProcess loaded when I ran cleanUpForProduction, and it stopped in an OSProcess class.

Without OSProcess, the I got a slightly different problem: the doesNotUnderstand of #run:with:in: is due to something in #cleanUpForRelease. Trying to debug it, new debuggers pop up, and then the emergency evaluator.

I have Seaside30/Magritte/Pier loaded, so I can try without those too. But, it used to work with all these things loaded.

-- Yanni

-- Mariano http://marianopeck.wordpress.com

On Tue, Jan 17, 2012 at 11:13 PM, Yanni Chiu <yanni@rogers.com> wrote:

On 17/01/12 4:44 PM, Mariano Martinez Peck wrote:

...

I have already opened an issue several months ago: http://code.google.com/p/**pharo/issues/detail?id=5005<http://code.google.com/p/pharo/issues/detail?id=5005>

I have also made it as much reproducable as I could and I have also asked for help: http://forum.world.st/Help-**with-cleanUpForRelease-is-** broken-MessageNotUnderstood-**ByteSymbol-run-with-in-** tp4205909p4205909.html<http://forum.world.st/Help-with-cleanUpForRelease-is-broken-MessageNotUnders...>

Yep, that's what I'm seeing. You end up with a Symbol where something else (a CompiledMethod?) is expected.

I tried the code from the bug report:

ClassOrganizer cleanUp: true. Smalltalk allClassesAndTraitsDo: [ :class | [ :each | each removeEmptyCategories; sortCategories ] value: class organization; value: class class organization ].

It did not cause any problem in either my new or old image (i.e. new is image derived from current build, and old is the base image I have been using, which did not have a problem before).

No, that was a mistake. The last one I could find to reproduce it is what I wrote in the last email: *" Well.....the maximum I got after a couple of hours is to be able to reproduce it executing TWO times (because the first one works) the following: "code that geenrates the bug" HashedCollection compactAll. Smalltalk removeEmptyMessageCategories. "Code to test the bug" Smalltalk allClassesAndTraitsDo: [ :class | [ :each | each removeEmptyCategories; sortCategories ] value: class organization; value: class class organization ]. If I do only HashedCollection compactAll or only Smalltalk removeEmptyMessageCategories., there is no problem, I can execute the rest without problems. If I do both (no matter which order), then the error happens. Moreover, I tried: (HashedCollection allSubclasses reject: [:each | each = MethodDictionary ]) do: #compactAllInstances. and that does work (no errors). So...somehow, the compact of the MethodDictionary is affecting something...what it is weird is that it only fails if the other code is executed... Anyway, any hint is appreciated. Thanks "* can you reproduce the problem with that ? -- Mariano http://marianopeck.wordpress.com

On 17/01/12 11:14 PM, Yanni Chiu wrote:

On 17/01/12 5:15 PM, Mariano Martinez Peck wrote:

...

can you reproduce the problem with that ?

Nope, the code worked in both the new and old images.

Here's how I've reproduced the problem. Happens about half the time out of a handful of times - using a new image (that was never saved). 1. Get a new Pharo1.4 download 2. Open browser on implementers of #cleanUp: 3. Find the HashedCollection class>>#cleanUp: method in the browser 4. Select "self compactAll" and doIt I've gotten the attached stacktrace twice, and it worked without problem another two times - even executed the code: Smalltalk allClassesAndTraitsDo: [...] to try to detect the problem, but when it worked, it worked.

Rats, that's not the fix. Even though #cleanUpForRelease ran to completion, running the code: Smalltalk allClassesAndTraitsDo: [ :class | [ :each | each removeEmptyCategories; sortCategories ] value: class organization; value: class class organization ]. still gives a ByteSymbol DNU for #run:with:in: I give up for now.

So is the new fix solving the problems? Stef On Jan 18, 2012, at 9:53 AM, Mariano Martinez Peck wrote:

On Wed, Jan 18, 2012 at 8:29 AM, Yanni Chiu <yanni@rogers.com> wrote: Rats, that's not the fix.

Even though #cleanUpForRelease ran to completion, running the code:

Smalltalk allClassesAndTraitsDo: [ :class | [ :each | each removeEmptyCategories; sortCategories ] value: class organization; value: class class organization ].

still gives a ByteSymbol DNU for #run:with:in:

I give up for now.

hahhah thanks Yanni. You see? it is really difficult to reproduce and understand :( thanks for your effort...

-- Mariano http://marianopeck.wordpress.com

On Jan 18, 2012, at 12:14 47PM, Mariano Martinez Peck wrote:

Well....it seems I found the problem. And in fact, it has alredy been solved by Levente in Squeak...I waste so many hours...and the fix was there..

So, can you try changing to

sizeFor: numberOfElements "Return the minimum capacity of a dictionary that can hold numberOfElements elements. At least 25% of the array must be empty and the return value must be a power of 2."

^(numberOfElements * 4 // 3) asLargerPowerOfTwo max: 1

And see if it works? it works here…

It should not be necessary. The real bug is that Integer >> isPowerOfTwo does not check for the edge case: 0 isPowerOfTwo true A small fix: Integer >> #isPowerOfTwo "Return true if the receiver is an integral power of two." ^ self ~= 0 and: [(self bitAnd: self-1) = 0] Cheers, Henry

On Jan 18, 2012, at 12:44 58PM, Mariano Martinez Peck wrote:

On Wed, Jan 18, 2012 at 12:25 PM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

On Jan 18, 2012, at 12:14 47PM, Mariano Martinez Peck wrote:

...

Well....it seems I found the problem. And in fact, it has alredy been solved by Levente in Squeak...I waste so many hours...and the fix was there..

So, can you try changing to

sizeFor: numberOfElements "Return the minimum capacity of a dictionary that can hold numberOfElements elements. At least 25% of the array must be empty and the return value must be a power of 2."

^(numberOfElements * 4 // 3) asLargerPowerOfTwo max: 1

And see if it works? it works here…

It should not be necessary. The real bug is that Integer >> isPowerOfTwo does not check for the edge case:

0 isPowerOfTwo true

A small fix:

Integer >> #isPowerOfTwo "Return true if the receiver is an integral power of two." ^ self ~= 0 and: [(self bitAnd: self-1) = 0]

Indeed :) now...even if that's correct, do you think there could be side effect in other places?

Not any that won't merely magically start working the way you expect them to, like say (looking at the senders): SmallInteger maxVal +1 numberOfDigitsInBase: 0 Cheers, Henry

On 18/01/12 6:25 AM, Henrik Johansen wrote:

The real bug is that Integer>> isPowerOfTwo does not check for the edge case:

That fixed it. #cleanUpForProduction now runs to completion.

Thanks. Mariano I remember that with marcus we got the same impression: that the copyFrom: trick to avoid a full scan was the cause of the trouble. But I remember that you said that you had still a problem.

Here's the fix:

I reverted MethodDictionary>>#compact to its previous version:

compact "Make sure that I have the highest possible load factor (at least 50%)."

self become: self compactWithoutBecome

The non-working version was:

compact "Make sure that I have the highest possible load factor (between 37.5% and 75%)."

| newInstance | newInstance := self compactWithoutBecome. newInstance capacity = self capacity ifTrue: [ self copyFrom: newInstance ] ifFalse: [ self becomeForward: newInstance ]

After reverting, #cleanUpForRelease worked without problem.