debug continuations with gem native code enabled

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

debug continuations with gem native code enabled

GLASS mailing list
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: debug continuations with gem native code enabled

GLASS mailing list
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 … :))


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: debug continuations with gem native code enabled

GLASS mailing list

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 … :))


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: debug continuations with gem native code enabled

GLASS mailing list
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 … :))


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: debug continuations with gem native code enabled

GLASS mailing list

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

On 04/20/2017 02:10 PM, Johan Brichau via Glass wrote:
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 … :))


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


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