[squeak-dev] Re: Debbuging problems, FFI

Andreas Raab andreas.raab at gmx.de
Sun Aug 2 18:06:50 UTC 2009


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.
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
> 
> 
> ------------------------------------------------------------------------
> 
> 




More information about the Squeak-dev mailing list