Thanks Javier Pimás and Andreas Raab for the excellent debugging and work. Andreas propose a fix (based in Javier work) and he has commited to Squeak. I look at the changes and try them in pharo. It works perfect!!!
So, here is the ticket I open for pharo: http://code.google.com/p/pharo/issues/detail?id=1029 You have to do 2 things to make it work: 1) download latest ffi (FFI-Kernel-ar.11). You can evaluate "ScriptLoader loadFFI" 2) filein the attached changeset (in ticket) to ContextPart>>doPrimitive: primitiveIndex method: meth receiver: receiver args: Please test it and let me know the results so that this can be integrated. For me it worked perfect. Best, Mariano 2009/8/2 Javier Pimás <[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]> > > >> >> 2009/7/31 Javier Pimás <[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]> 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]> >>>> >>>> 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]> >>>>> >>>>>> 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] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [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] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [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] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
