On 03.08.2009, at 23:57, Javier Pimás wrote:
> I'm glad it worked, and very pleased with the fast responses. Now,
> how does this patch get merged to the pharo trunk?
>
Can you add an entry to the bugtracker?
http://code.google.com/p/pharo/issues/list
I should have some good description or a changeset or a SLICE. Than I
add it to pharo today...
Marcus
> The other thing I'd like to find out is why when using self break, I
> get in the debugger inspector a context where variables have wrong
> values. I'll open another thread on this.
>
> 2009/8/3 Mariano Martinez Peck <[email protected]>
> 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
>
>
>
> --
> 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
