Smalltalk › Squeak › Squeak VM

Reproducible way to crash Cog ( [Lsehub-staff] Strange behavior )

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Igor Stasenko

Reproducible way to crash Cog ( [Lsehub-staff] Strange behavior )

Hello, Eliot

today i tried to help and see what is strange (see original message
below).. and followed the instructions, but instead of 'strange' i got
VM crash. ;)

I tried multiple Mac Cog VMs (one built by me, another, built by you),
and both crashing during GC.

To reproduce, take the latest pharo-core image
(http://www.pharo-project.org/pharo-download/unstable-core)
Then evaluate following:

Gofer new
squeaksource: 'Seed';
package: 'Seed-HaselBuilder';
load.

Then evaluate
HaselKernelBuilder new script.

if next to that you do (if it not crashed already)

Smalltalk garbageCollect.

and VM will crash guaranteed (or become unresponsive).

I didn't investigated deeply, but i found that culprit is most probably in
HaselKernelBuilder>>copyClass:

@ Benjamin. You have a mistake in your code (and that i think why it
behaves 'strange')
you setting the class of class to be the instance of 'metacopy'

so, you have

class copy -> metaclass copy basicNew -> metaclass copy

('->' here means 'instance of' )

while it should be

class copy -> metaclass copy

So

cpy primitiveChangeClassTo: metaCopy basicNew.

actually should be

cpy primitiveChangeClassTo: metaCopy.

---------- Forwarded message ----------
From: Benjamin <[hidden email]>
Date: 8 December 2010 17:15
Subject: [Lsehub-staff] Strange behavior
To: RMoD private list <[hidden email]>

Hello guys,

I've a strange error when I'm trying to trace some objects, and even
after spending the whole day on it, I still do not understand why, so
if you have any idea, you're welcome :)

Source :

Gofer new
squeaksource: 'Seed';
package: 'Seed-HaselBuilder';
load.

Method :

Then open a Transcript and evaluate

HaselKernelBuilder new script.
tracedObjects := Dictionary new. objects := Dictionary new. object :=
Object. HaselImageBuilder new trace: object in: objects from: nil
tracedObjects: tracedObjects.

Thank you in advance,

Ben

--
Best regards,
Igor Stasenko AKA sig.

Eliot Miranda-2

Re: Reproducible way to crash Cog ( [Lsehub-staff] Strange behavior )

Hi Igor,

thanks for this. Note to self: this is in ~/Squeak/PharoCore-1.2-12261

BTW, you can try and build the debug VM and use that. It has asserts built-in that may find the problem earlier. The mvm script makes a Debug.app by default.

HTH

Eliot

On Wed, Dec 8, 2010 at 1:28 PM, Igor Stasenko <[hidden email]> wrote:

Hello, Eliot

today i tried to help and see what is strange (see original message
below).. and followed the instructions, but instead of 'strange' i got
VM crash. ;)

I tried multiple Mac Cog VMs (one built by me, another, built by you),
and both crashing during GC.

To reproduce, take the latest pharo-core image
(http://www.pharo-project.org/pharo-download/unstable-core)
Then evaluate following:

Gofer new
squeaksource: 'Seed';
package: 'Seed-HaselBuilder';
load.

Then evaluate
HaselKernelBuilder new script.

if next to that you do (if it not crashed already)

Smalltalk garbageCollect.

and VM will crash guaranteed (or become unresponsive).

I didn't investigated deeply, but i found that culprit is most probably in
HaselKernelBuilder>>copyClass:

@ Benjamin. You have a mistake in your code (and that i think why it
behaves 'strange')
you setting the class of class to be the instance of 'metacopy'

so, you have

class copy -> metaclass copy basicNew -> metaclass copy

('->' here means 'instance of' )

while it should be

class copy -> metaclass copy

So

cpy primitiveChangeClassTo: metaCopy basicNew.

actually should be

cpy primitiveChangeClassTo: metaCopy.

---------- Forwarded message ----------
From: Benjamin <[hidden email]>
Date: 8 December 2010 17:15
Subject: [Lsehub-staff] Strange behavior
To: RMoD private list <[hidden email]>

Hello guys,

I've a strange error when I'm trying to trace some objects, and even
after spending the whole day on it, I still do not understand why, so
if you have any idea, you're welcome :)

Source :

Gofer new
squeaksource: 'Seed';
package: 'Seed-HaselBuilder';
load.

Method :

Then open a Transcript and evaluate

HaselKernelBuilder new script.
tracedObjects := Dictionary new. objects := Dictionary new. object :=
Object. HaselImageBuilder new trace: object in: objects from: nil
tracedObjects: tracedObjects.

Thank you in advance,

Ben

--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko

Re: Reproducible way to crash Cog ( [Lsehub-staff] Strange behavior )

In reply to this post by Igor Stasenko

On 8 December 2010 22:41, Benjamin <[hidden email]> wrote:

>
> On Dec 8, 2010, at 10:28 PM, Igor Stasenko wrote:
>
>> Hello, Eliot
>>
>> today i tried to help and see what is strange (see original message
>> below).. and followed the instructions, but instead of 'strange' i got
>> VM crash. ;)
>>
>> I tried multiple Mac Cog VMs (one built by me, another, built by you),
>> and both crashing during GC.
>>
>> To reproduce, take the latest pharo-core image
>> (http://www.pharo-project.org/pharo-download/unstable-core)
>> Then evaluate following:
>>
>> Gofer new
>> squeaksource: 'Seed';
>> package: 'Seed-HaselBuilder';
>> load.
>>
>>
>> Then evaluate
>> HaselKernelBuilder new script.
>>
>> if next to that you do (if it not crashed already)
>>
>> Smalltalk garbageCollect.
>>
>>
>> and VM will crash guaranteed (or become unresponsive).
>>
>> I didn't investigated deeply, but i found that culprit is most probably in
>> HaselKernelBuilder>>copyClass:
>>
>>
>>
>> @ Benjamin. You have a mistake in your code (and that i think why it
>> behaves 'strange')
>> you setting the class of class to be the instance of 'metacopy'
>>
>> so, you have
>>
>> class copy -> metaclass copy basicNew -> metaclass copy
>>
>> ('->' here means 'instance of' )
>>
>> while it should be
>>
>> class copy -> metaclass copy
>>
>> So
>>
>> cpy primitiveChangeClassTo: metaCopy basicNew.
>>
>> actually should be
>>
>> cpy primitiveChangeClassTo: metaCopy.
>>
>
> In fact, this primitive take the class of the argument to change the class
> of the receiver (yes I know, it's strange ...)

ah, sorry, my fault. Then its should be ok to do like that.
But i got another crash before getting to that line , so i didn't have
change to test it.
It seems something wrong happening during method copying.

I never used this prim before, so i didn't knew that it takes the
class of argument,
instead an argument itself as a class to which replace receiver's class.

>
> The 'strange' behavior is also a crash from the VM, but not in the kernel
> creation.
>
>
> Thank you for your advice (and the beach volley ^^)
>
> Ben
>
>
>>
>> ---------- Forwarded message ----------
>> From: Benjamin <[hidden email]>
>> Date: 8 December 2010 17:15
>> Subject: [Lsehub-staff] Strange behavior
>> To: RMoD private list <[hidden email]>
>>
>>
>> Hello guys,
>>
>> I've a strange error when I'm trying to trace some objects, and even
>> after spending the whole day on it, I still do not understand why, so
>> if you have any idea, you're welcome :)
>>
>>
>> Source :
>>
>> Gofer new
>> squeaksource: 'Seed';
>> package: 'Seed-HaselBuilder';
>> load.
>>
>>
>> Method :
>>
>> Then open a Transcript and evaluate
>>
>> HaselKernelBuilder new script.
>> tracedObjects := Dictionary new. objects := Dictionary new. object :=
>> Object. HaselImageBuilder new trace: object in: objects from: nil
>> tracedObjects: tracedObjects.
>>
>>
>> Thank you in advance,
>>
>>
>> Ben
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
>

--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko

Re: Reproducible way to crash Cog ( [Lsehub-staff] Strange behavior )

In reply to this post by Eliot Miranda-2

On 8 December 2010 22:43, Eliot Miranda <[hidden email]> wrote:
> Hi Igor,
> thanks for this. Note to self: this is in ~/Squeak/PharoCore-1.2-12261
> BTW, you can try and build the debug VM and use that. It has asserts
> built-in that may find the problem earlier. The mvm script makes a
> Debug.app by default.

yeah, i will take a look at it tomorrow.
Benjamin's code mangling with compiled methods, and i don't know if
there are anything ok with it.
But anyways, if there are a chance to close the security hole, which
is uncovered by his code, we should do that :)

P.S. it is something really strange happening to Cog GC on Mac (or
maybe it is i too lucky) , remember my previous
problem with pow() function used inside fullGC(), which also leaded to
crash. Once i rewrote the code to use bit shifts,
it works normally.

It is always happen to newbie (being lucky), because they don't know
the rough corners of system and can discover something, which others
can't never discover, because they won't even think to do something
like newbie does, because they taught to do otherwise :)

> HTH
> Eliot
>

--
Best regards,
Igor Stasenko AKA sig.

Andreas.Raab

Re: Reproducible way to crash Cog ( [Lsehub-staff] Strange behavior )

In reply to this post by Igor Stasenko

On 12/8/2010 1:58 PM, Igor Stasenko wrote:
> I never used this prim before, so i didn't knew that it takes the
> class of argument,
> instead an argument itself as a class to which replace receiver's class.

The primitive is an odd beast. I added it as a quick and dirty solution
way back when I was trying to fix various issues around ClassBuilder.
The reason it uses an instance instead of the class is that testing for
compatibility between the receiver and argument is a simple format
check, whereas when using the class you need to extract all sorts of
assorted information (such as whether the argument is a compact class
and the receiver is a compact class, if the number of instance slot
matches, if it's an indexed object or not) that is not immediately
accessible from a class.

I am amazed people actually use the primitive for something but let me
say this loud and clear: This primitive is not intended to be used
casually. In fact the comment states explicitly that:

"The facility is really provided for certain, very specific
applications (mostly related to classes changing shape) and not for
casual use."

Cheers,
- Andreas

Igor Stasenko

Re: Reproducible way to crash Cog ( [Lsehub-staff] Strange behavior )

On 8 December 2010 23:14, Andreas Raab <[hidden email]> wrote:

>
> On 12/8/2010 1:58 PM, Igor Stasenko wrote:
>>
>> I never used this prim before, so i didn't knew that it takes the
>> class of argument,
>> instead an argument itself as a class to which replace receiver's class.
>
> The primitive is an odd beast. I added it as a quick and dirty solution way
> back when I was trying to fix various issues around ClassBuilder. The reason
> it uses an instance instead of the class is that testing for compatibility
> between the receiver and argument is a simple format check, whereas when
> using the class you need to extract all sorts of assorted information (such
> as whether the argument is a compact class and the receiver is a compact
> class, if the number of instance slot matches, if it's an indexed object or
> not) that is not immediately accessible from a class.
>
> I am amazed people actually use the primitive for something but let me say
> this loud and clear: This primitive is not intended to be used casually. In
> fact the comment states explicitly that:
>
> "The facility is really provided for certain, very specific
> applications (mostly related to classes changing shape) and not for casual
> use."

yes, Benjamin actually could avoid using it by copying a metaclass first,
and then doing
meta basicNew

and use the result as a 'copy' of class, and then copy only necessary
ivars from old class to this one.

>
> Cheers,
> - Andreas
>

--
Best regards,
Igor Stasenko AKA sig.

Eliot Miranda-2

Re: Reproducible way to crash Cog ( [Lsehub-staff] Strange behavior )

In reply to this post by Andreas.Raab

On Wed, Dec 8, 2010 at 2:14 PM, Andreas Raab <[hidden email]> wrote:

On 12/8/2010 1:58 PM, Igor Stasenko wrote:

I never used this prim before, so i didn't knew that it takes the
class of argument,
instead an argument itself as a class to which replace receiver's class.

VisualWorks also started off with a changeClassToThatOf: primitive which took an instance. We fixed that by providing behavior>adoptInstance:. This still has to extract format info form the receiver (a class) but at least the primitive can assume the receiver is a valid behavior and it only has to check if the argument is suitable as an instance of the class.

I wrote this for Cog also, see primitiveAdoptInstance, #160, so if you find this more convenient you can use it; find attached.

HTH

Eliot

The primitive is an odd beast. I added it as a quick and dirty solution way back when I was trying to fix various issues around ClassBuilder. The reason it uses an instance instead of the class is that testing for compatibility between the receiver and argument is a simple format check, whereas when using the class you need to extract all sorts of assorted information (such as whether the argument is a compact class and the receiver is a compact class, if the number of instance slot matches, if it's an indexed object or not) that is not immediately accessible from a class.

I am amazed people actually use the primitive for something but let me say this loud and clear: This primitive is not intended to be used casually. In fact the comment states explicitly that:

"The facility is really provided for certain, very specific applications (mostly related to classes changing shape) and not for casual use."

Cheers,
- Andreas

Behavior-adoptInstance.st (2K) Download Attachment

Henrik Sperre Johansen

Re: Reproducible way to crash Cog ( [Lsehub-staff] Strange behavior )

On Dec 8, 2010, at 11:42 00PM, Eliot Miranda wrote:

On Wed, Dec 8, 2010 at 2:14 PM, Andreas Raab <[hidden email]> wrote:

On 12/8/2010 1:58 PM, Igor Stasenko wrote:

I never used this prim before, so i didn't knew that it takes the
class of argument,
instead an argument itself as a class to which replace receiver's class.

VisualWorks also started off with a changeClassToThatOf: primitive which took an instance. We fixed that by providing behavior>adoptInstance:. This still has to extract format info form the receiver (a class) but at least the primitive can assume the receiver is a valid behavior and it only has to check if the argument is suitable as an instance of the class.

I wrote this for Cog also, see primitiveAdoptInstance, #160, so if you find this more convenient you can use it; find attached.

HTH
Eliot

Weee, I've missed the adoptInstance: method!

While I agree it's nothing to use regularly, it can be fun to play around with.

F.ex, I used the primitive some time ago in an evil/clever experiment to remove depth instVar / methods which branch on depth from Form.

So, to have a method which works on both Cog and non-Cog, could we write:

Behavior >> #adoptInstance: anInstance

<primitive: 160 error: ec>

^anInstance changeClassToThatOf: self basicNew

Or are the failure cases different?

Cheers,

Henry

Eliot Miranda-2

Re: Reproducible way to crash Cog ( [Lsehub-staff] Strange behavior )

On Thu, Dec 9, 2010 at 3:10 AM, Henrik Johansen <[hidden email]> wrote:

On Dec 8, 2010, at 11:42 00PM, Eliot Miranda wrote:

On Wed, Dec 8, 2010 at 2:14 PM, Andreas Raab <[hidden email]> wrote:

On 12/8/2010 1:58 PM, Igor Stasenko wrote:

I never used this prim before, so i didn't knew that it takes the
class of argument,
instead an argument itself as a class to which replace receiver's class.

VisualWorks also started off with a changeClassToThatOf: primitive which took an instance. We fixed that by providing behavior>adoptInstance:. This still has to extract format info form the receiver (a class) but at least the primitive can assume the receiver is a valid behavior and it only has to check if the argument is suitable as an instance of the class.

I wrote this for Cog also, see primitiveAdoptInstance, #160, so if you find this more convenient you can use it; find attached.

HTH
Eliot

Weee, I've missed the adoptInstance: method!
While I agree it's nothing to use regularly, it can be fun to play around with.
F.ex, I used the primitive some time ago in an evil/clever experiment to remove depth instVar / methods which branch on depth from Form.

So, to have a method which works on both Cog and non-Cog, could we write:

Behavior >> #adoptInstance: anInstance
<primitive: 160 error: ec>
^anInstance changeClassToThatOf: self basicNew

Or are the failure cases different?

I think it'll be close enough. Go for it.

Cheers,
Henry