[squeak-dev] Re: Debbuging problems, FFIIgor Stasenko siguctua at gmail.comMon Aug 3 02:57:29 UTC 2009
2009/8/2 Andreas Raab <andreas.raab at gmx.de>: > 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? > Cheers, > - Andreas > >> >> Thanks, >> >> Mariano >> >> >> ---------- Forwarded message ---------- >> From: *Javier Pimás* <elpochodelagente at gmail.com >> <mailto:elpochodelagente at gmail.com>> >> Date: 2009/8/2 >> Subject: Re: [Pharo-project] Debbuging problems, FFI >> To: Pharo-project at lists.gforge.inria.fr >> <mailto:Pharo-project at lists.gforge.inria.fr> >> >> >> 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 <marianopeck at gmail.com >> <mailto:marianopeck at gmail.com>> >> >> >> >> 2009/7/31 Javier Pimás <elpochodelagente at gmail.com >> <mailto:elpochodelagente at gmail.com>> >> >> 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 >> <elpochodelagente at gmail.com <mailto:elpochodelagente at gmail.com>> >> 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 <marianopeck at gmail.com >> <mailto:marianopeck at gmail.com>> >> >> 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 <elpochodelagente at gmail.com >> <mailto:elpochodelagente at gmail.com>> >> >> 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 >> Pharo-project at lists.gforge.inria.fr >> <mailto:Pharo-project at lists.gforge.inria.fr> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project at lists.gforge.inria.fr >> <mailto:Pharo-project at lists.gforge.inria.fr> >> >> 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 >> Pharo-project at lists.gforge.inria.fr >> <mailto:Pharo-project at lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project at lists.gforge.inria.fr >> <mailto:Pharo-project at lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> -- >> Javier Pimás >> Ciudad de Buenos Aires >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project at lists.gforge.inria.fr >> <mailto:Pharo-project at lists.gforge.inria.fr> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> ------------------------------------------------------------------------ >> >> > > > -- Best regards, Igor Stasenko AKA sig.
More information about the Squeak-dev mailing list |