[Pharo-project] Wrapper bug (is ByteSurgeon the cause of it ?)
Hi all, I have a very strange bug when I use method wrappers. Here is my wrapper code (actually it does nothing but calling the method) : ProtoObject variableSubclass: #Wrapper instanceVariableNames: 'compiledMethod' classVariableNames: '' poolDictionaries: '' category: 'Wrapper-Core' Wrapper>>#doesNotUnderstand: aMessage ^aMessage sendTo: compiledMethod Wrapper>>#run: aSymbol with: arguments in: rec ^rec withArgs: arguments executeMethod: compiledMethod Wrapper>>#compiledMethod: c compiledMethod:=c. ^self Now I want to execute this : SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper new compiledMethod: (SequenceableCollection>>#copyFrom:to:)). It works fine with a new pharo-dev image. But if I install ByteSurgeon before that, it crashes the VM if I click on the workspace for instance. I just don't know what possibly happen, any help would be very appreciated :) Regards, Antoine ------ Antoine Marot Ph.D Student Université Libre de Bruxelles Département d'Informatique
can you try on something less sensitive than copyFrom:to: to debug it? Stef On Nov 14, 2008, at 4:59 PM, Antoine Marot wrote:
Hi all,
I have a very strange bug when I use method wrappers.
Here is my wrapper code (actually it does nothing but calling the method) :
ProtoObject variableSubclass: #Wrapper instanceVariableNames: 'compiledMethod' classVariableNames: '' poolDictionaries: '' category: 'Wrapper-Core'
Wrapper>>#doesNotUnderstand: aMessage ^aMessage sendTo: compiledMethod
Wrapper>>#run: aSymbol with: arguments in: rec ^rec withArgs: arguments executeMethod: compiledMethod
Wrapper>>#compiledMethod: c compiledMethod:=c. ^self
Now I want to execute this :
SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper new compiledMethod: (SequenceableCollection>>#copyFrom:to:)).
It works fine with a new pharo-dev image. But if I install ByteSurgeon before that, it crashes the VM if I click on the workspace for instance.
I just don't know what possibly happen, any help would be very appreciated :)
Regards,
Antoine
------ Antoine Marot Ph.D Student Université Libre de Bruxelles Département d'Informatique _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
For now it works fine on other methods. That's why I don't get what the problem might be. Unfortunately, my project requires to be able to wrap any method and to instrument it with ByteSurgeon. Antoine Le 14-nov.-08 à 20:57, Stéphane Ducasse a écrit :
can you try on something less sensitive than copyFrom:to: to debug it?
Stef
On Nov 14, 2008, at 4:59 PM, Antoine Marot wrote:
Hi all,
I have a very strange bug when I use method wrappers.
Here is my wrapper code (actually it does nothing but calling the method) :
ProtoObject variableSubclass: #Wrapper instanceVariableNames: 'compiledMethod' classVariableNames: '' poolDictionaries: '' category: 'Wrapper-Core'
Wrapper>>#doesNotUnderstand: aMessage ^aMessage sendTo: compiledMethod
Wrapper>>#run: aSymbol with: arguments in: rec ^rec withArgs: arguments executeMethod: compiledMethod
Wrapper>>#compiledMethod: c compiledMethod:=c. ^self
Now I want to execute this :
SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper new compiledMethod: (SequenceableCollection>>#copyFrom:to:)).
It works fine with a new pharo-dev image. But if I install ByteSurgeon before that, it crashes the VM if I click on the workspace for instance.
I just don't know what possibly happen, any help would be very appreciated :)
Regards,
Antoine
------ Antoine Marot Ph.D Student Université Libre de Bruxelles Département d'Informatique _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In 3.9 you can wrap it with bytesurgeon? Stef On Nov 14, 2008, at 9:16 PM, Antoine Marot wrote:
For now it works fine on other methods. That's why I don't get what the problem might be.
Unfortunately, my project requires to be able to wrap any method and to instrument it with ByteSurgeon.
Antoine
Le 14-nov.-08 à 20:57, Stéphane Ducasse a écrit :
can you try on something less sensitive than copyFrom:to: to debug it?
Stef
On Nov 14, 2008, at 4:59 PM, Antoine Marot wrote:
Hi all,
I have a very strange bug when I use method wrappers.
Here is my wrapper code (actually it does nothing but calling the method) :
ProtoObject variableSubclass: #Wrapper instanceVariableNames: 'compiledMethod' classVariableNames: '' poolDictionaries: '' category: 'Wrapper-Core'
Wrapper>>#doesNotUnderstand: aMessage ^aMessage sendTo: compiledMethod
Wrapper>>#run: aSymbol with: arguments in: rec ^rec withArgs: arguments executeMethod: compiledMethod
Wrapper>>#compiledMethod: c compiledMethod:=c. ^self
Now I want to execute this :
SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper new compiledMethod: (SequenceableCollection>>#copyFrom:to:)).
It works fine with a new pharo-dev image. But if I install ByteSurgeon before that, it crashes the VM if I click on the workspace for instance.
I just don't know what possibly happen, any help would be very appreciated :)
Regards,
Antoine
------ Antoine Marot Ph.D Student Université Libre de Bruxelles Département d'Informatique _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
No I can't... So I guess ByteSurgeon (or its installation) is the problem here. Marcus> Do you have any idea about this ? Antoine Le 14-nov.-08 à 21:35, Stéphane Ducasse a écrit :
In 3.9 you can wrap it with bytesurgeon?
Stef
On Nov 14, 2008, at 9:16 PM, Antoine Marot wrote:
For now it works fine on other methods. That's why I don't get what the problem might be.
Unfortunately, my project requires to be able to wrap any method and to instrument it with ByteSurgeon.
Antoine
Le 14-nov.-08 à 20:57, Stéphane Ducasse a écrit :
can you try on something less sensitive than copyFrom:to: to debug it?
Stef
On Nov 14, 2008, at 4:59 PM, Antoine Marot wrote:
Hi all,
I have a very strange bug when I use method wrappers.
Here is my wrapper code (actually it does nothing but calling the method) :
ProtoObject variableSubclass: #Wrapper instanceVariableNames: 'compiledMethod' classVariableNames: '' poolDictionaries: '' category: 'Wrapper-Core'
Wrapper>>#doesNotUnderstand: aMessage ^aMessage sendTo: compiledMethod
Wrapper>>#run: aSymbol with: arguments in: rec ^rec withArgs: arguments executeMethod: compiledMethod
Wrapper>>#compiledMethod: c compiledMethod:=c. ^self
Now I want to execute this :
SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper new compiledMethod: (SequenceableCollection>>#copyFrom:to:)).
It works fine with a new pharo-dev image. But if I install ByteSurgeon before that, it crashes the VM if I click on the workspace for instance.
I just don't know what possibly happen, any help would be very appreciated :)
Regards,
Antoine
------ Antoine Marot Ph.D Student Université Libre de Bruxelles Département d'Informatique _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 15.11.2008, at 17:03, Antoine Marot wrote:
No I can't... So I guess ByteSurgeon (or its installation) is the problem here.
Marcus> Do you have any idea about this ?
Not directly... I will have a look... Marcus
Antoine
Le 14-nov.-08 à 21:35, Stéphane Ducasse a écrit :
In 3.9 you can wrap it with bytesurgeon?
Stef
On Nov 14, 2008, at 9:16 PM, Antoine Marot wrote:
For now it works fine on other methods. That's why I don't get what the problem might be.
Unfortunately, my project requires to be able to wrap any method and to instrument it with ByteSurgeon.
Antoine
Le 14-nov.-08 à 20:57, Stéphane Ducasse a écrit :
can you try on something less sensitive than copyFrom:to: to debug it?
Stef
On Nov 14, 2008, at 4:59 PM, Antoine Marot wrote:
Hi all,
I have a very strange bug when I use method wrappers.
Here is my wrapper code (actually it does nothing but calling the method) :
ProtoObject variableSubclass: #Wrapper instanceVariableNames: 'compiledMethod' classVariableNames: '' poolDictionaries: '' category: 'Wrapper-Core'
Wrapper>>#doesNotUnderstand: aMessage ^aMessage sendTo: compiledMethod
Wrapper>>#run: aSymbol with: arguments in: rec ^rec withArgs: arguments executeMethod: compiledMethod
Wrapper>>#compiledMethod: c compiledMethod:=c. ^self
Now I want to execute this :
SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper new compiledMethod: (SequenceableCollection>>#copyFrom:to:)).
It works fine with a new pharo-dev image. But if I install ByteSurgeon before that, it crashes the VM if I click on the workspace for instance.
I just don't know what possibly happen, any help would be very appreciated :)
Regards,
Antoine
------ Antoine Marot Ph.D Student Université Libre de Bruxelles Département d'Informatique _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
One new clue to solve this bug: the problem only happen when the code is runned from a workspace. It works when runned in a testcase by the test runner. Antoine Le 16-nov.-08 à 17:04, Marcus Denker a écrit :
On 15.11.2008, at 17:03, Antoine Marot wrote:
No I can't... So I guess ByteSurgeon (or its installation) is the problem here.
Marcus> Do you have any idea about this ?
Not directly... I will have a look...
Marcus
Antoine
Le 14-nov.-08 à 21:35, Stéphane Ducasse a écrit :
In 3.9 you can wrap it with bytesurgeon?
Stef
On Nov 14, 2008, at 9:16 PM, Antoine Marot wrote:
For now it works fine on other methods. That's why I don't get what the problem might be.
Unfortunately, my project requires to be able to wrap any method and to instrument it with ByteSurgeon.
Antoine
Le 14-nov.-08 à 20:57, Stéphane Ducasse a écrit :
can you try on something less sensitive than copyFrom:to: to debug it?
Stef
On Nov 14, 2008, at 4:59 PM, Antoine Marot wrote:
Hi all,
I have a very strange bug when I use method wrappers.
Here is my wrapper code (actually it does nothing but calling the method) :
ProtoObject variableSubclass: #Wrapper instanceVariableNames: 'compiledMethod' classVariableNames: '' poolDictionaries: '' category: 'Wrapper-Core'
Wrapper>>#doesNotUnderstand: aMessage ^aMessage sendTo: compiledMethod
Wrapper>>#run: aSymbol with: arguments in: rec ^rec withArgs: arguments executeMethod: compiledMethod
Wrapper>>#compiledMethod: c compiledMethod:=c. ^self
Now I want to execute this :
SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper new compiledMethod: (SequenceableCollection>>#copyFrom:to:)).
It works fine with a new pharo-dev image. But if I install ByteSurgeon before that, it crashes the VM if I click on the workspace for instance.
I just don't know what possibly happen, any help would be very appreciated :)
Regards,
Antoine
------ Antoine Marot Ph.D Student Université Libre de Bruxelles Département d'Informatique _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 14.11.2008, at 16:59, Antoine Marot wrote:
Hi all,
I have a very strange bug when I use method wrappers.
Here is my wrapper code (actually it does nothing but calling the method) :
ProtoObject variableSubclass: #Wrapper instanceVariableNames: 'compiledMethod' classVariableNames: '' poolDictionaries: '' category: 'Wrapper-Core'
Wrapper>>#doesNotUnderstand: aMessage ^aMessage sendTo: compiledMethod
Wrapper>>#run: aSymbol with: arguments in: rec ^rec withArgs: arguments executeMethod: compiledMethod
Wrapper>>#compiledMethod: c compiledMethod:=c. ^self
Now I want to execute this :
SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper new compiledMethod: (SequenceableCollection>>#copyFrom:to:)).
Very strage... I think in general it is not good to use the doesNotUnderstand trick so deeply in the system... for example, even #hash and #= and will be taken from the wrappee (the compiledMethod), but not #==, as it's in ProtoObject. And #class will never get forwarded (as it's a bytecode). So maybe the #hash is the problem: on the image side, #hash gets forwarded to the wrappee, but what does the VM do? There could be a mismatch. (and recompiling the whole image, what bytesurgeon installer does, could change something wrt. to hashing that this makes it a problem whereas it might not been a problem before) Another thing: you need to empty the VM cashes when installing a method by calling #flushCache (or use Bahvior>>#basicAddSelector:withMethod:). Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Le 25-nov.-08 à 14:00, Marcus Denker a écrit :
Very strage... I think in general it is not good to use the doesNotUnderstand trick so deeply in the system... for example, even #hash and #= and will be taken from the wrappee (the compiledMethod), but not #==, as it's in ProtoObject. And #class will never get forwarded (as it's a bytecode).
So maybe the #hash is the problem: on the image side, #hash gets forwarded to the wrappee, but what does the VM do? There could be a mismatch. (and recompiling the whole image, what bytesurgeon installer does, could change something wrt. to hashing that this makes it a problem whereas it might not been a problem before)
I think you're right. Having a CompiledMethod as wrapper instead of a class with the doesNotUnderstand trick makes it work. Your explanation perfectly fits that for me :) Thank you, Antoine
participants (3)
-
Antoine Marot -
Marcus Denker -
Stéphane Ducasse