On Sun, Aug 2, 2009 at 11:57 PM, Igor Stasenko <[email protected]> wrote:
> 2009/8/2 Andreas Raab <[email protected]>: > > Mariano Martinez Peck wrote: > >> > >> Javier has done an excellent job and here is his last post. Can someone > >> read what he found and see if we can fix this annoying bug? > > > > The problem is that you can't call #valueWithReceiver:args: since this > would > > both execute the entire method and do it in the wrong context where > instead > > you need to execute *just* the primitive (since you'll simulate the rest > if > > it fails). > > > > Fortunately, external functions have two ways to invoke them; one > implicitly > > as primitive in a method (i.e., prim 120) and another one explicitly (via > > invokeWithArgs:). A variant on the latter that returns > > ContextPart>>primFailToken does the trick nicely. > > > > I've updated both http://source.squeak.org/FFI and > > http://source.squeak.org/trunk with the ncessary bits. > > Andreas, does your change fixes the issue? Because its not clear from > your message - is it solves the problem altogether, or it is just a > first step towards proper fix? > Thanks Igor. I had the same questions as you. However, I downloaded that new version, and tried but I got same results (the behaviour of the first email). I mean, when I did step over in the api call I landed in and in MethodContext(ContextPart)>>runUntilErrorOrReturnFrom: > > > Cheers, > > - Andreas > > > >> > >> Thanks, > >> > >> Mariano > >> > >> > >> ---------- Forwarded message ---------- > >> From: *Javier Pimás* <[email protected] > >> <mailto:[email protected]>> > >> Date: 2009/8/2 > >> Subject: Re: [Pharo-project] Debbuging problems, FFI > >> To: [email protected] > >> <mailto:[email protected]> > >> > >> > >> I Think I found where the problem lies, it's just sitting there waiting > to > >> be resolved. > >> > >> To see what was happening I debugged the debuger, which was really > weird. > >> I found the answer when I broke into the step over button by adding a > self > >> break in OTCmdOverDebugger>>execute. After catching it I removed the > break > >> and stepped into everything to see how step over worked. The intresting > part > >> is in MethodContext(ContextPart)>>step, which sends > >> interpretNextInstructionFor: self. The idea is this, instead of > advancing > >> the vm program counter within the vm code, the debugger simulates the > >> execution cycle, step by step. It not so hard as it seems but also not > very > >> simple. The problem comes when the debugger tryies to simulate primitive > >> calls. When the simulator detects a primitive, it issues a > >> MethodContext(ContextPart)>>doPrimitive:method:receiver:args:, here you > can > >> see the detection: > >> > >> tryPrimitiveFor: method receiver: receiver args: arguments > >> "..." > >> | primIndex | > >> (primIndex := method primitive) = 0 ifTrue: [^ PrimitiveFailToken]. > >> ^ self doPrimitive: primIndex method: method receiver: receiver args: > >> arguments > >> > >> well, the problem is that doPrimitive doesn't seem to implement all > >> primitives (I recomend you to look it's code), but just a few ones. > Also, as > >> far as I can see, it calls primitive 19, which i found is (by looking vm > C > >> code) primitiveFail, and that primitive just sets a flag that says that > >> something failed. > >> > >> Then, if my calculations are correct, the problem is that the FFI Call > >> primitive needs to be handled by hand. I tryied adding this to > >> ContextPart>>doPrimitive:method:receiver:args: > >> > >> primitiveIndex = 120 ifTrue: "Calling an FFI method, just evaluate it > and > >> return" > >> [ meth valueWithReceiver: receiver arguments: arguments . ^self]. > >> > >> just before > >> > >> arguments size > 6 ifTrue: [^PrimitiveFailToken]. > >> > >> which I think almost worked. I think the primitive was executed, but > this > >> doesn't handle the execution context that is being simulated, and the > stack > >> gets corrupted. Somebody with more experience in ContextPart, > MethodContext, > >> etc. may give us a hand here, I think the fix is almost there. > >> > >> Bye, > >> Javier. > >> > >> 2009/7/31 Mariano Martinez Peck <[email protected] > >> <mailto:[email protected]>> > >> > >> > >> > >> 2009/7/31 Javier Pimás <[email protected] > >> <mailto:[email protected]>> > >> > >> Does anybody know if the problem occurs just in Windows or in > >> any OS? this can give a clue of the problem... > >> > >> > >> I don't remember debugging in Windows, but in Linux I have this > >> problem for sure. > >> > >> > >> On Thu, Jul 30, 2009 at 11:28 PM, Javier Pimás > >> <[email protected] <mailto:[email protected]>> > >> wrote: > >> > >> Well, at least I feel better that I'm not crazy, (or not the > >> only one...). Maybe if someone could give us a clue about > >> it, we could spot where the problem is. Do you think it is a > >> vm problem or something related to the smalltalk code? > >> > >> 2009/7/30 Mariano Martinez Peck <[email protected] > >> <mailto:[email protected]>> > >> > >> Yes. This is really annoying for me. I am writing a C > >> library plugin since a year and a half and this is very > >> frustrated :( > >> You cannot debug when using FFI. I mean, you cannot get > >> advantages of one of the best Smalltalk features! What I > >> do is to write a self break before and after the call > >> and use "proceed" but I don't like it at all. > >> > >> Once I tried to see what the problem was, but I was to > >> difficult to me to understand it and fix it. We need a > >> guru here I think hahaha. > >> > >> Best, > >> > >> Mariano > >> > >> 2009/7/30 Javier Pimás <[email protected] > >> <mailto:[email protected]>> > >> > >> Hi, I'm having problems with the debugger. Every > >> time I try to debug code that uses FFI, if I step > >> over a message that internally does an FFI call, I > >> get an externalCallFailed error and then I land in > >> > MethodContext(ContextPart)>>runUntilErrorOrReturnFrom: > >> If I run the code without debugging, then I have no > >> problems at all. > >> > >> I'm using SqueakPharo v3.11.2 with > >> pharo0.1-10373web09.07.2. > >> > >> To reproduce it you can try this: > >> > >> ScriptLoader loadFFI. > >> then load latest GLMorphic from squeaksource, and > >> uncomment the "self break." in > >> GLCanvas>>displayString:from:to:at:strikeFont:kern: > >> > >> doit > >> World fullDrawOn: GLDisplayScreen testCanvas > >> hit debug and step over until you reach > >> ogl glTexImage2D: GLTexture2d with:... > >> > >> also you'll see wrong values for local vars, like > >> aPoint which will look as #(nil nil nil nil nil) > >> when it'll actually have a point. > >> > >> Is there any other way to set up a break point > >> instead of adding self break to the code?? > >> > >> Thanks, > >> Javier. > >> > >> -- Javier Pimás > >> Ciudad de Buenos Aires > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [email protected] > >> <mailto:[email protected]> > >> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [email protected] > >> <mailto:[email protected]> > >> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> > >> > >> -- Javier Pimás > >> Ciudad de Buenos Aires > >> > >> > >> > >> > >> -- Javier Pimás > >> Ciudad de Buenos Aires > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [email protected] > >> <mailto:[email protected]> > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [email protected] > >> <mailto:[email protected]> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> > >> > >> -- > >> Javier Pimás > >> Ciudad de Buenos Aires > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [email protected] > >> <mailto:[email protected]> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> ------------------------------------------------------------------------ > >> > >> > > > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
