...

Now I do not understand why this guy cannot get printed.

I do not see why

ClassDescription>>printOn: aStream aStream nextPutAll: self name

Metaclass>>name "Answer a String that is the name of the receiver, either 'Metaclass' or the name of the receiver's class followed by ' class'."

thisClass == nil ifTrue: [^'a Metaclass'] ifFalse: [^thisClass name , ' class']

self first soleInstance printString -> leads to have emergency debugger.

you do not get emergency! I do not like when we do not get the same bugs…

self name shows:

a Dictionary(#DependentsFields->a WeakIdentityKeyDictionary(a CategoryWidget->a DependentsArray(a PluggableIconListMorph(217841664)) a ContextVariablesInspector->a DependentsArray(a PluggableListMorph(445382656) a PluggableTextMorph(1046216704)) a ContextVariablesInspector->a DependentsArray(a PluggableListMorph(290193408) ... )

The source of printing problems will be in thisClass.

The next interesting thing is that it has no pointers and it is removed after garbageCollect.

So this is a good news :).

-- Pavel

...

Stef

On Wed, May 9, 2012 at 3:39 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

...

Now I do not understand why this guy cannot get printed.

I do not see why

ClassDescription>>printOn: aStream        aStream nextPutAll: self name

Metaclass>>name        "Answer a String that is the name of the receiver, either 'Metaclass' or        the name of the receiver's class followed by ' class'."

       thisClass == nil                ifTrue: [^'a Metaclass']                ifFalse: [^thisClass name , ' class']

self first soleInstance printString        -> leads to have emergency debugger.

you do not get emergency! I do not like when we do not get the same bugs…

on some inst vars and expressions I get the emergency evaluator.

...

self name shows:

a Dictionary(#DependentsFields->a WeakIdentityKeyDictionary(a CategoryWidget->a DependentsArray(a PluggableIconListMorph(217841664)) a ContextVariablesInspector->a DependentsArray(a PluggableListMorph(445382656) a PluggableTextMorph(1046216704)) a ContextVariablesInspector->a DependentsArray(a PluggableListMorph(290193408) ... )

The source of printing problems will be in thisClass.

The next interesting thing is that it has no pointers and it is removed after garbageCollect.

So this is a good news :).

The question is what produced such strange object and how many similar ones we still have in the image. It can have very unwelcome consequences - for example the segmentation faults on Fuel packages exports when executed from command line. But from workspace it behaves differently. -- Pavel

...

-- Pavel

...

Stef

On May 10, 2012, at 1:19 AM, Francisco Garau wrote:

It also happened on a 20032 image (see screenshot).

Smalltalk cleanUp didn't solve the issue here.

Please, note the Unnamed Changeset with a Dictionary…

Tx Franscico Indeed it looks like something weird happened. Stef

- Francisco

On 9 May 2012 20:27, Pavel Krivanek <pavel.krivanek@gmail.com> wrote: On Wed, May 9, 2012 at 3:39 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

...

...

Now I do not understand why this guy cannot get printed.

I do not see why

ClassDescription>>printOn: aStream aStream nextPutAll: self name

Metaclass>>name "Answer a String that is the name of the receiver, either 'Metaclass' or the name of the receiver's class followed by ' class'."

thisClass == nil ifTrue: [^'a Metaclass'] ifFalse: [^thisClass name , ' class']

self first soleInstance printString -> leads to have emergency debugger.

you do not get emergency! I do not like when we do not get the same bugs…

on some inst vars and expressions I get the emergency evaluator.

...

...

self name shows:

a Dictionary(#DependentsFields->a WeakIdentityKeyDictionary(a CategoryWidget->a DependentsArray(a PluggableIconListMorph(217841664)) a ContextVariablesInspector->a DependentsArray(a PluggableListMorph(445382656) a PluggableTextMorph(1046216704)) a ContextVariablesInspector->a DependentsArray(a PluggableListMorph(290193408) ... )

The source of printing problems will be in thisClass.

The next interesting thing is that it has no pointers and it is removed after garbageCollect.

So this is a good news :).

The question is what produced such strange object and how many similar ones we still have in the image. It can have very unwelcome consequences - for example the segmentation faults on Fuel packages exports when executed from command line. But from workspace it behaves differently.

-- Pavel

...

...

-- Pavel

...

Stef

<Screen shot 2012-05-10 at 00.12.55.png>

I had the same idea but the build history is quite short (7) and with our updating speed it is filled within two days :-) I extended the builds count yesterday to 20. The next interesting information about dzindizik: o := ((Metaclass allInstances detect: [:c | c superclass = ProtoObject class]) instVarNamed: #thisClass). 1. "number here to avoid printing". Smalltalk allClasses select: [:c | o isKindOf: c] -> an OrderedCollection(Behavior Class ClassDescription Object ProtoObject) Smalltalk allClasses select: [:c | o class == c] -> an OrderedCollection() It looks like a subclass of Class :-) -- Pavel On Wed, May 9, 2012 at 1:24 PM, Herby Vojčík <herby@mailbox.sk> wrote:

Hi,

just an idea: maybe bisecting and finding which update brought it in and then analyzing its changes may help... or you know it is 20059?

Herby

Pavel Krivanek wrote:

...

Hi,

If you take the latest Pharo 2.0 image from Jenkins (20059) and you execute the expression:

(Metaclass allInstances select: [:c | c superclass = ProtoObject class]) inspect

you will get an collection inspector where the first object is very strange one. It is very hard to get any useful information about the origin of this evil object. The only thing we know exactly is that it causes virtual machine segmentation faults while trying to export class ScrollBar via Fuel. Not only CogVM but even StackVM.

Can you, please, try to help us to get as much information as possible about this object? I named it "dzindzik" :-)

Cheers, -- Pavel

thank you, version 51 is already infected. Has anyone some build between? -- Pavel On Wed, May 9, 2012 at 1:47 PM, Francisco Garau <francisco.garau@gmail.com> wrote:

Evaluating your code in #build 2041 returns only the 3 expected classes:

(Metaclass allInstances select: [:c | c superclass = ProtoObject class]) inspect => {Object class. MessageCatcher class. TestCoverage class}

On 9 May 2012 12:35, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:

...

I had the same idea but the build history is quite short (7) and with our updating speed it is filled within two days :-) I extended the builds count yesterday to 20.

The next interesting information about dzindizik:

o := ((Metaclass allInstances detect: [:c | c superclass = ProtoObject class]) instVarNamed: #thisClass). 1. "number here to avoid printing".

Smalltalk allClasses select: [:c | o isKindOf: c] -> an OrderedCollection(Behavior Class ClassDescription Object ProtoObject)

Smalltalk allClasses select: [:c | o class == c] -> an OrderedCollection()

It looks like a subclass of Class :-)

-- Pavel

On Wed, May 9, 2012 at 1:24 PM, Herby Vojčík <herby@mailbox.sk> wrote:

...

Hi,

just an idea: maybe bisecting and finding which update brought it in and then analyzing its changes may help... or you know it is 20059?

Herby

Pavel Krivanek wrote:

...

Hi,

If you take the latest Pharo 2.0 image from Jenkins (20059) and you execute the expression:

(Metaclass allInstances select: [:c | c superclass = ProtoObject class]) inspect

you will get an collection inspector where the first object is very strange one. It is very hard to get any useful information about the origin of this evil object. The only thing we know exactly is that it causes virtual machine segmentation faults while trying to export class ScrollBar via Fuel. Not only CogVM but even StackVM.

Can you, please, try to help us to get as much information as possible about this object? I named it "dzindzik" :-)

Cheers, -- Pavel

Pavel Krivanek wrote:

Some next interesting information:

o := ((Metaclass allInstances detect: [:c | c superclass = ProtoObject class]) instVarNamed: #thisClass). 1.

Smalltalk allClassesAndTraits select: [:c | o isKindOf: c] -> an OrderedCollection(Behavior Class ClassDescription Object ProtoObject)

Smalltalk allClasses select: [:c | o class == c] -> an OrderedCollection() "WTF"

My gut feeling says 'o class == o' here. Also it may be interesting to see what is o class class. (o class is not inspectable, is it?) Herby

Pavel Krivanek wrote:

On Wed, May 9, 2012 at 2:38 PM, Herby Vojčík<herby@mailbox.sk> wrote:

...

Pavel Krivanek wrote:

...

Some next interesting information:

o := ((Metaclass allInstances detect: [:c | c superclass = ProtoObject class]) instVarNamed: #thisClass). 1.

Smalltalk allClassesAndTraits select: [:c | o isKindOf: c] -> an OrderedCollection(Behavior Class ClassDescription Object ProtoObject)

Smalltalk allClasses select: [:c | o class == c] -> an OrderedCollection() "WTF"

My gut feeling says 'o class == o' here. Also it may be interesting to see what is o class class. (o class is not inspectable, is it?)

As I see there is a circle but different one:

dzindzik := (Metaclass allInstances detect: [:c | c superclass = ProtoObject class]). 1. o := dzindzik instVarNamed: #thisClass. 1. o class == dzindzik -> true ... what just says it's a metaclass...

BTW, o methodDict is inspectable, it has size 338 and definitely is something from morphic taken from method names. Obviously :-) Smalltalk allClasses select: [ :c | c class methodDict size = 338] => anOrderedCollection() Herby

-- Pavel

...

Herby

I've seen a similar object in the first pharo 2.0 image I have downloaded. It was in an Unamed ChangSet (right at the bottom of the list) Cannot check right now... - Francisco On 9 May 2012, at 14:13, Herby Vojčík <herby@mailbox.sk> wrote:

Herby Vojčík wrote:

...

Pavel Krivanek wrote:

...

On Wed, May 9, 2012 at 2:38 PM, Herby Vojčík<herby@mailbox.sk> wrote:

...

Pavel Krivanek wrote:

...

Some next interesting information:

o := ((Metaclass allInstances detect: [:c | c superclass = ProtoObject class]) instVarNamed: #thisClass). 1.

Smalltalk allClassesAndTraits select: [:c | o isKindOf: c] -> an OrderedCollection(Behavior Class ClassDescription Object ProtoObject)

Smalltalk allClasses select: [:c | o class == c] -> an OrderedCollection() "WTF"

My gut feeling says 'o class == o' here. Also it may be interesting to see what is o class class. (o class is not inspectable, is it?)

As I see there is a circle but different one:

dzindzik := (Metaclass allInstances detect: [:c | c superclass = ProtoObject class]). 1. o := dzindzik instVarNamed: #thisClass. 1. o class == dzindzik -> true

It seems there is a problem with inst var indexes... just look at o name (it's printable, only it's a dictionary with dependent fields), something you would not wait from AClass name.

Herby

P.S.: dzindzik name and dzindzik methodDict are inspectable... method dict is normal, but name is again something strange...

On Wed, May 9, 2012 at 3:31 PM, Herby Vojčík <herby@mailbox.sk> wrote:

The cause of the problem is probably in this: if you try to inspect dzindzik, VM prints out something like "Directory does not have index: 7". If you try dzindzik instVarAt:1, dzindzik instVarAt:2, ... in a row, you get 6, but there is not 7.

This is related to the instVar 'layout' that was added to Behavior. If you analyze dzindzik, its correct. I mean, the order in its instVars are correct. Its problem is "thisClass". As you could notice, you could not inspect thisClass because you get an error with the "Directory does not have index: 7". So, go to SystemWindows and change this method to:

SystemWindow >> #labelled: labelString ^self new setLabel: 'caca' What we do is to be able to open the inspector while avoiding to ask for its class for the label (since it is broken). Now you are able to inspect thisClass. When you inspect this class, you will see that the first instVars (superclass, methodDict and format) are all correct. 'layout' is nil and from there, all instVars are shifted one slot. The instvar instanceVariables have a classOrganizer. The instVar subclasses has the name, etc... so... thisClass subclasses -> #Object Of course, you cannot inspect the last instVar 'localSelectors' because you are going out of the scope ;) In summary it looks like dzindzik is anoher Metaclass of Object, say Object class (whose instVars are correct), and dzindzik class is Object but with broken (shifted) instVars. That's all we could fine so far with Guille :)

So dzindzik's class thinks it has (at least) seven inst vars, but in fact in does only have six.

Herby

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

On May 9, 2012, at 2:14 PM, Pavel Krivanek wrote:

Some next interesting information:

o := ((Metaclass allInstances detect: [:c | c superclass = ProtoObject class]) instVarNamed: #thisClass). 1.

Smalltalk allClassesAndTraits select: [:c | o isKindOf: c] -> an OrderedCollection(Behavior Class ClassDescription Object ProtoObject)

Smalltalk allClasses select: [:c | o class == c] -> an OrderedCollection() "WTF"

o subclasses -> #Object "WTF!" o subclasses class -> ByteSymbol "WTF!! should be Array" o superclass -> ProtoObject "WTF" (o methodDict keys asSortedCollection first: 50) = (Object methodDict keys asSortedCollection first: 50) -> true "wasn't it Object in better times?"

Is WTF? Really strange. Pavel you can tell the updater to update until a certain number.

The object is not present in the latest 2.0 image, it was eaten by GC. -- Pavel 23.6.2012 v 9:47, Stéphane Ducasse <stephane.ducasse@inria.fr>:

Hi guys

what is the status of this problem? Because hilaire has some problem with drGeo and we should check how to help him.

Stef On May 8, 2012, at 11:49 PM, Pavel Krivanek wrote:

...

Hi,

If you take the latest Pharo 2.0 image from Jenkins (20059) and you execute the expression:

(Metaclass allInstances select: [:c | c superclass = ProtoObject class]) inspect

you will get an collection inspector where the first object is very strange one. It is very hard to get any useful information about the origin of this evil object. The only thing we know exactly is that it causes virtual machine segmentation faults while trying to export class ScrollBar via Fuel. Not only CogVM but even StackVM.

Can you, please, try to help us to get as much information as possible about this object? I named it "dzindzik" :-)

Cheers, -- Pavel