2009/7/31 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:

Javier,

I have little experience debugging around Squeak/Pharo FFI, so I will simply offer something the popped into my head based on Dolphin experience.  Are you certain of the return and argument types?  Every so often, I feed Dolphin nonsense in one of those areas, and the results can be spectacular, especially the fallout from a bogus return type.

Sorry I cannot be of any real help.

This is something which i waiting to be fixed for a while: http://bugs.squeak.org/view.php?id=6436

Bill

________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Javier Pimás Sent: Thursday, July 30, 2009 5:03 PM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Debbuging problems, FFI

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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Javier Pimás Ciudad de Buenos Aires

2009/7/31 Javier Pimás <elpochodelagente@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@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi folks, In Pharo mailing list, there are people trying to fix the known bug when debugging with FFI. The bug report is this: http://bugs.squeak.org/view.php?id=6436 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? Thanks, Mariano ---------- Forwarded message ---------- From: Javier Pimás <elpochodelagente@gmail.com> Date: 2009/8/2 Subject: Re: [Pharo-project] Debbuging problems, FFI To: Pharo-project@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@gmail.com>

2009/7/31 Javier Pimás <elpochodelagente@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@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I'm glad it worked, and very pleased with the fast responses. Now, how does this patch get merged to the pharo trunk? 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 <marianopeck@gmail.com>

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 <elpochodelagente@gmail.com>

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@gmail.com>

...

2009/7/31 Javier Pimás <elpochodelagente@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@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Javier Pimás Ciudad de Buenos Aires

2009/8/4 Mariano Martinez Peck <marianopeck@gmail.com>

2009/8/4 Javier Pimás <elpochodelagente@gmail.com>

...

I'm glad it worked, and very pleased with the fast responses. Now, how does this patch get merged to the pharo trunk?

Did it work for you ? When people say the fix actually works well, it will be closed and commited to pharo inbox (I can do it) and then integrated in a new image. I would be obviously be lovely to have a unit test for this, but I don't don't know if this is possible. What do you think?

It worked fine for me. About the test, I think it can be done, at the level of MethodContext>>tryPrimitiveFor: method receiver: receiver args: arguments. The problem would be how to get the correct parameters to test. method could be something like the CompiledMethod related to Win32Window>>getFocus (but should better be something os-independent) receiver would then be Win32Window and arguments just #(). The question is where will aMethodContext come from.

...

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.

I didn't understand you, but yes, please open a new thread and ticket if necessary.

Best,

Mariano

...

2009/8/3 Mariano Martinez Peck <marianopeck@gmail.com>

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 <elpochodelagente@gmail.com>

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@gmail.com>

...

2009/7/31 Javier Pimás <elpochodelagente@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@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Javier Pimás Ciudad de Buenos Aires

On Tue, Aug 4, 2009 at 12:30 PM, Marcus Denker <denker@acm.org> wrote:

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, I already opened the ticket: 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: I am just looking for testers and feedback before commiting it to pharo inbox. Best, Mariano

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 <marianopeck@gmail.com> 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 <elpochodelagente@gmail.com>

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@gmail.com>

2009/7/31 Javier Pimás <elpochodelagente@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@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project