debug continuations with gem native code enabled

Haha ... re-reading Mariano's comment on the commit, I should mention that breakpoints can be set/honored when running  with native code enabled, but the breakpoint cannot be set in the same process that will hit the breakpoint --- which would be the issue that Mariano is referring to ... I think ... If breakpoints have been set and a new process starts up, then the thread is run in interpreted mode (breakpoints are only honored when a thread is running in interpreted mode) ... once all breakpoints have been cleared, new processes starting up will run in native code mode again ...

Dale

Hi,

Following up on myself :)

Seems like this issue [1] is what I experience.

Fixed by applying the same code changes.

… catching up to do … :))

[1] https://github.com/GsDevKit/Seaside31/commit/ed70a052141d50b621c478e2e8db03398a627763

On 20 Apr 2017, at 18:54, Johan Brichau <[hidden email]> wrote:

Hi there,

I don’t seem to be able to inspect a continuation’s stack trace in the object log when running Seaside 3.0.x gems in a GemStone 3.2 with gem native code enabled.
Trying to open the stack trace in Gemtools runs into an error 'a MessageNotUnderstood occurred (error 2010), a UndefinedObject does not understand  #'localMethodAt:’

Did not try to use tODE yet in this case but is this to be expected or am I probably misconfiguring something somewhere?

thx for any pointers
Johan

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Johan,

I'm referring to the process inspecting the error stack for GemTools ... the seaside gems are all running native code and are unaffected by the continuation code ...

Dale,

Not sure if I understand what’s going on.

Since applying that patch with ‘self halt’ in the `saveExceptionContinuation` method, I can inspect the stack of the errors being logged again from gemtools.

Does this mean the Seaside gems are not running in native code anymore? 

Or do you refer to the process inspecting the error stack? (more logically, I think)..

Johan

On 20 Apr 2017, at 22:39, Dale Henrichs via Glass <[hidden email]> wrote:

Haha ... re-reading Mariano's comment on the commit, I should mention that breakpoints can be set/honored when running  with native code enabled, but the breakpoint cannot be set in the same process that will hit the breakpoint --- which would be the issue that Mariano is referring to ... I think ... If breakpoints have been set and a new process starts up, then the thread is run in interpreted mode (breakpoints are only honored when a thread is running in interpreted mode) ... once all breakpoints have been cleared, new processes starting up will run in native code mode again ...

Dale

On 04/20/2017 01:29 PM, Johan Brichau via Glass wrote:

Hi,

Following up on myself :)

Seems like this issue [1] is what I experience.

Fixed by applying the same code changes.

… catching up to do … :))

[1] https://github.com/GsDevKit/Seaside31/commit/ed70a052141d50b621c478e2e8db03398a627763

On 20 Apr 2017, at 18:54, Johan Brichau <[hidden email]> wrote:

Hi there,

I don’t seem to be able to inspect a continuation’s stack trace in the object log when running Seaside 3.0.x gems in a GemStone 3.2 with gem native code enabled.
Trying to open the stack trace in Gemtools runs into an error 'a MessageNotUnderstood occurred (error 2010), a UndefinedObject does not understand  #'localMethodAt:’

Did not try to use tODE yet in this case but is this to be expected or am I probably misconfiguring something somewhere?

thx for any pointers
Johan

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass