strange problem in CompiledMethod>>=

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

strange problem in CompiledMethod>>=

Tudor Girba-2
Hi,

One of the Moose test runs a visualization that manipulates CompiledMethods, and it runs into an error when trying to find an entry inside a dictionary that has compiled methods as keys. In the end, I managed to isolate the problem that can be reproduced by:

1. Download the moose image:
https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/artifact/moose-latest-dev-4.8.zip

2. Execute:
(MooseIncomingQueryResult>>#selectDependencies:) = (MooseOutgoingInvocationQueryResult>>#selectDependencies:).


It seems it is a Pharo problem, or something related to these particular methods. Would anyone be interested in looking into this?

Cheers,
Doru


--
www.tudorgirba.com

"Obvious things are difficult to teach."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: strange problem in CompiledMethod>>=

Tudor Girba-2
Hi,

I have put together a little analysis and got to 684 problematic pairs in the Moose image:

allCompiledMethods := Object withAllSubclasses flatCollect: #methods.
problematicCases := OrderedCollection new.
allCompiledMethods allPairsDo: [ :a :b |
        [a = b] on: Error do: [ problematicCases add: a->b ] ].
FileSystem disk workingDirectory / 'problematicCompiledMethodsEquality.txt' writeStreamDo: [ :stream |
        problematicCases associationsDo: [ :each |
                stream nextPutAll: '(', each key printString, ') = (', each value printString, ')'; cr ] ]

It takes a while to run this, so I put the result in the attachment. There are quite a number of problematic comparisons that can be reproduced in the original Pharo image, too, so I think we found a bug.

Cheers,
Doru




On Mar 28, 2013, at 6:59 AM, Tudor Girba <[hidden email]> wrote:

> Hi,
>
> One of the Moose test runs a visualization that manipulates CompiledMethods, and it runs into an error when trying to find an entry inside a dictionary that has compiled methods as keys. In the end, I managed to isolate the problem that can be reproduced by:
>
> 1. Download the moose image:
> https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/artifact/moose-latest-dev-4.8.zip
>
> 2. Execute:
> (MooseIncomingQueryResult>>#selectDependencies:) = (MooseOutgoingInvocationQueryResult>>#selectDependencies:).
>
>
> It seems it is a Pharo problem, or something related to these particular methods. Would anyone be interested in looking into this?
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
>
> "Obvious things are difficult to teach."
>
>
>
--
www.tudorgirba.com

"Don't give to get. Just give."






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

problematicCompiledMethodsEquality.txt (64K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] strange problem in CompiledMethod>>=

Marcus Denker-4
In reply to this post by Tudor Girba-2

On Mar 28, 2013, at 6:59 AM, Tudor Girba <[hidden email]> wrote:

> Hi,
>
> One of the Moose test runs a visualization that manipulates CompiledMethods, and it runs into an error when trying to find an entry inside a dictionary that has compiled methods as keys. In the end, I managed to isolate the problem that can be reproduced by:
>
> 1. Download the moose image:
> https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/artifact/moose-latest-dev-4.8.zip
>
> 2. Execute:
> (MooseIncomingQueryResult>>#selectDependencies:) = (MooseOutgoingInvocationQueryResult>>#selectDependencies:).
>
>
> It seems it is a Pharo problem, or something related to these particular methods. Would anyone be interested in looking into this?
>
Yes, equality just check that the byte code is the same. Historically this is the behavior as methods did not know
their class nor their selector, at some point they where then including this information for #=, but the latest does
not.

We should change it, Methods now contain the information in which class they are installed in and it should be
taken into account for =

There is already a case:

        https://pharo.fogbugz.com/f/cases/7222

        Marcus


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] strange problem in CompiledMethod>>=

Marcus Denker-4

On Mar 28, 2013, at 8:05 AM, Marcus Denker <[hidden email]> wrote:

>
> On Mar 28, 2013, at 6:59 AM, Tudor Girba <[hidden email]> wrote:
>
>> Hi,
>>
>> One of the Moose test runs a visualization that manipulates CompiledMethods, and it runs into an error when trying to find an entry inside a dictionary that has compiled methods as keys. In the end, I managed to isolate the problem that can be reproduced by:
>>
>> 1. Download the moose image:
>> https://ci.inria.fr/moose/job/moose-latest-dev-4.8/lastSuccessfulBuild/artifact/moose-latest-dev-4.8.zip
>>
>> 2. Execute:
>> (MooseIncomingQueryResult>>#selectDependencies:) = (MooseOutgoingInvocationQueryResult>>#selectDependencies:).
>>

Hmm… I think I was completely wrong. The problem is that the methods are from a Trait and something goes wrong because of
that. I think the problem is the #traitSource annotation, it seems that the code for = has problems when properties are defined
on methods.

        Marcus


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev