Hi all,
Do you know when this fix will be added in a new squeak vm release ?
I really need it for my thesis... So I tried to build the vm (without VMMaker since it doesn't want to be loaded...).
This is how I tried to fix the interp.c file (it's probably wrong since this doesn't fix anything) :
sqInt primitiveExecuteMethod(void) { register struct foo * foo = &fum; sqInt top; sqInt successValue; sqInt primIdx; sqInt nArgs; sqInt delta; sqInt primBits;
/* begin popStack */ top = longAt(foo->stackPointer); foo->stackPointer -= BytesPerWord; foo->newMethod = top; /* begin primitiveIndexOf: */ primBits = (((usqInt) (longAt((foo->newMethod + BaseHeaderSize) + (HeaderIndex << ShiftForWord)))) >> 1) & 268435967; foo->primitiveIndex = (primBits & 511) + (((usqInt) primBits) >> 19); /* begin success: */ successValue = (foo->argumentCount - 1) == ((((usqInt) (longAt((foo-
newMethod + BaseHeaderSize) + (HeaderIndex << ShiftForWord)))) >>
25) & 15); foo->successFlag = successValue && foo->successFlag; if (foo->successFlag) { foo->argumentCount -= 1; /* begin executeNewMethod */ if (foo->primitiveIndex > 0) { /* begin primitiveResponse */ if (DoBalanceChecks) { nArgs = foo->argumentCount; delta = foo->stackPointer - foo->activeContext; } primIdx = foo->primitiveIndex; foo->successFlag = 1; dispatchFunctionPointerOnin(primIdx, primitiveTable); if (DoBalanceChecks) { if (!(balancedStackafterPrimitivewithArgs(delta, primIdx, nArgs))) { printUnbalancedStack(primIdx); } } if (foo->successFlag) { goto l1; } } activateNewMethod(); /* begin quickCheckForInterrupts */ if ((foo->interruptCheckCounter -= 1) <= 0) { checkForInterrupts(); } l1: /* end executeNewMethod */; foo->successFlag = 1; } else { /* begin unPop: */ foo->stackPointer += 1 * BytesPerWord; } }
Basically, I just added "foo->successFlag = 1;" after /* end executeNewMethod */;.
Cheers,
Antoine
Date: Oct 28, 2008; 12:55am Author: Eliot Miranda-2 Squeak - Dev (http://www.nabble.com/Squeak---Dev-f14154.html) Well I actually wrote the fix as
primitiveExecuteMethod "receiver, args, then method are on top of stack. Execute method against receiver and args" newMethod := self popStack. primitiveIndex := self primitiveIndexOf: newMethod. self success: argumentCount - 1 = (self argumentCountOf: newMethod). successFlag ifTrue: [argumentCount := argumentCount - 1. self executeNewMethod. "Recursive xeq affects successFlag" successFlag := true] ifFalse: [self unPop: 1]
to agree with the perform code. The fix is to ensure that successFlag is true.
2008/11/20 Antoine Marot amarot@ulb.ac.be:
Hi all, Do you know when this fix will be added in a new squeak vm release ? I really need it for my thesis... So I tried to build the vm (without VMMaker since it doesn't want to be loaded...). This is how I tried to fix the interp.c file (it's probably wrong since this doesn't fix anything) :
Yes, its wrong. Please try load VMMaker and fix code in smalltalk instead. The C code is a mess, generated by VMMaker, and you should never do anything with it, except some debugging and checking if it generates code correctly.
Thank you Igor for your reply.
I finally succeeded in making a VM :) (I still have to print my squeak VM builder certificate and display it proudly ;) ).
Does anyone know approximately when this fix should be added to an official release ? This bug seriously makes it hard for me to share my code...
Best regards,
Antoine
--- Antoine Marot Ph.D Student Département d'Informatique Université Libre de Bruxelles
Le 20-nov.-08 à 16:33, Igor Stasenko a écrit :
2008/11/20 Antoine Marot amarot@ulb.ac.be:
Hi all, Do you know when this fix will be added in a new squeak vm release ? I really need it for my thesis... So I tried to build the vm (without VMMaker since it doesn't want to be loaded...). This is how I tried to fix the interp.c file (it's probably wrong since this doesn't fix anything) :
Yes, its wrong. Please try load VMMaker and fix code in smalltalk instead. The C code is a mess, generated by VMMaker, and you should never do anything with it, except some debugging and checking if it generates code correctly.
-- Best regards, Igor Stasenko AKA sig.
On Sun, 23 Nov 2008 15:38:42 +0100, Antoine Marot wrote:
Thank you Igor for your reply.
I finally succeeded in making a VM :) (I still have to print my squeak VM builder certificate and display it proudly ;) ).
Well done, congratulations :)
Does anyone know approximately when this fix should be added to an official release ? This bug seriously makes it hard for me to share my code...
I understand that what you need is "... method valueWithReceiver:arguments: is used hugely with method wrappers" and you need it without VM bug when a primitive fails.
Perhaps a stupid question (I don't know any other your requirements) but instead of wrapping methods one could easily #perform: a selector on the receiver. What would be the reason that you depend on #valueWithReceiver:arguments: ? it cannot be performance since #perform: needs some time as well.
/Klaus
Best regards,
Antoine
Antoine Marot Ph.D Student Département d'Informatique Université Libre de Bruxelles
Le 20-nov.-08 à 16:33, Igor Stasenko a écrit :
2008/11/20 Antoine Marot amarot@ulb.ac.be:
Hi all, Do you know when this fix will be added in a new squeak vm release ? I really need it for my thesis... So I tried to build the vm (without VMMaker since it doesn't want to be loaded...). This is how I tried to fix the interp.c file (it's probably wrong since this doesn't fix anything) :
Yes, its wrong. Please try load VMMaker and fix code in smalltalk instead. The C code is a mess, generated by VMMaker, and you should never do anything with it, except some debugging and checking if it generates code correctly.
--Best regards, Igor Stasenko AKA sig.
Does anyone know approximately when this fix should be added to an official release ? This bug seriously makes it hard for me to share my code...
I understand that what you need is "... method valueWithReceiver:arguments: is used hugely with method wrappers" and you need it without VM bug when a primitive fails.
Perhaps a stupid question (I don't know any other your requirements) but instead of wrapping methods one could easily #perform: a selector on the receiver. What would be the reason that you depend on #valueWithReceiver:arguments: ? it cannot be performance since #perform: needs some time as well.
/Klaus
The goal of my wrappers is to choose (depending on the context) between the original method and an instrumented one.
The calling code is similar to this :
receiver withArgs: args executeMethod: (context-condition ifTrue: [transformedMethod] ifFalse: [originalMethod] )
Note that I don't use #valueWithReceiver:, but the bug also appears with that method.
Since #perform: goes through the method lookup process, it will loop unless I use two new selectors. This solution has several disadvantages like implying a second lookup process or not being invisible (the new method dictionary entries appear in browsers and are editable which is problematic).
Antoine
On Sun, 23 Nov 2008 17:51:42 +0100, Antoine Marot wrote:
Does anyone know approximately when this fix should be added to an official release ? This bug seriously makes it hard for me to share my code...
Further to the below I checked http://bugs.squeak.org and there was not report? I think you (or Frederic) have to report the bug before it officially is one ...
I understand that what you need is "... method valueWithReceiver:arguments: is used hugely with method wrappers" and you need it without VM bug when a primitive fails.
Perhaps a stupid question (I don't know any other your requirements) but instead of wrapping methods one could easily #perform: a selector on the receiver. What would be the reason that you depend on #valueWithReceiver:arguments: ? it cannot be performance since #perform: needs some time as well.
/Klaus
The goal of my wrappers is to choose (depending on the context) between the original method and an instrumented one.
The calling code is similar to this :
receiver withArgs: args executeMethod: (context-condition ifTrue: [transformedMethod] ifFalse: [originalMethod] )
Note that I don't use #valueWithReceiver:, but the bug also appears with that method.
Since #perform: goes through the method lookup process, it will loop unless I use two new selectors. This solution has several disadvantages like implying a second lookup process or not being invisible (the new method dictionary entries appear in browsers and are editable which is problematic).
Okay, understood (I think so ;) Perhaps there is a workaround (namely: the Smalltalk simulator) for Squeak, which you can give a try:
The debugger apparently knows how to perform a primitive by number, look at #tryPrimitive:withArgs: its implementor and sender.
If you do that and it returns (ContextPart primitiveFailToken) then do the "primitiveFailed" part, using #withArgs:executeMethod: as above *but* on a *clone* of the originalMethod into which you put primitive number 0 (repeat: the clone!).
HTH.
/Klaus
Antoine
Le 23-nov.-08 à 19:39, Klaus D. Witzel a écrit :
Further to the below I checked http://bugs.squeak.org and there was not report? I think you (or Frederic) have to report the bug before it officially is one ...
Ok, I'll do that :)
Okay, understood (I think so ;) Perhaps there is a workaround (namely: the Smalltalk simulator) for Squeak, which you can give a try:
The debugger apparently knows how to perform a primitive by number, look at #tryPrimitive:withArgs: its implementor and sender.
If you do that and it returns (ContextPart primitiveFailToken) then do the "primitiveFailed" part, using #withArgs:executeMethod: as above *but* on a *clone* of the originalMethod into which you put primitive number 0 (repeat: the clone!).
Excellent idea ! Thank you very much !
Antoine
squeak-dev@lists.squeakfoundation.org