[Glass] Debugging from Seaside. Sometimes OK, sometimes hung

Hi guys. There is something I don't understand. I am debugging a seaside app running in GemStone from GemClient. The thing is that some errors open a debugger directly in GemTools image (coool!) and others open the Seaside walkback page. There, if I press debug.... the GemClient hungs. I can interrupt GemStone but nothing happens. And after sime time I get a 

---

From: "Mariano Martinez Peck" <[hidden email]>
To: [hidden email]
Sent: Wednesday, November 13, 2013 10:28:48 AM
Subject: [Glass] Debugging from Seaside. Sometimes OK, sometimes hung

Hi guys. There is something I don't understand. I am debugging a seaside app running in GemStone from GemClient. The thing is that some errors open a debugger directly in GemTools image (coool!) and others open the Seaside walkback page. There, if I press debug....

Okay, I brought up seaside using the zinc adaptor and went to the http://localhost:4343/tests/functional/WAFlowErrorFunctionalTest page and click on `Raise Error link and I get a Seaside stack in the web browser ... When I click on the Debug link I get a walkback opened in my client ... So let's see if that works for you ..

When the  debbuger opens up directly in GemTools, that means that you have a hit an error that is outside the Seaside "application stack" which means that it is a Seaside infrastructure error or a Zinc error (or whatever web server you happen to be using) ... When the debug stack shows up in the web browser, that means you have hit an error that is within your seaside application and the seaside error handling facility is invoked ... you have a number of options for dealing with Seaside errors in GemStone[1]. Each of the different error handlers has different characteristics ...

The set handler field on the Error page tells you which error handler you are currently using, so I will be interested to know which one is set for you. If the debugger opens correctly from the error page, then I'll need to learn more about your specific error that causes the hang ...

[1] https://code.google.com/p/glassdb/wiki/Seaside30ErrorHandlers

the GemClient hungs. I can interrupt GemStone but nothing happens. And after sime time I get a 

 'Network error - text follows: , from GciAstFailureNetwork partner has disconnected.'

There might actually be a crash involved here and it is worth checking the gem log file for errors ... you should be able to find the gem log in /opt/gemstone/log ... look at the most recent gemnet*.log file and see if there is an error stack there ...

Dale

---

From: "Mariano Martinez Peck" <[hidden email]>
To: "Dale K. Henrichs" <[hidden email]>
Cc: [hidden email]
Sent: Thursday, November 14, 2013 5:41:52 AM
Subject: Re: [Glass] Debugging from Seaside. Sometimes OK, sometimes hung

On Wed, Nov 13, 2013 at 4:04 PM, Dale K. Henrichs <[hidden email]> wrote:

---

From: "Mariano Martinez Peck" <[hidden email]>
To: [hidden email]
Sent: Wednesday, November 13, 2013 10:28:48 AM
Subject: [Glass] Debugging from Seaside. Sometimes OK, sometimes hung

Hi guys. There is something I don't understand. I am debugging a seaside app running in GemStone from GemClient. The thing is that some errors open a debugger directly in GemTools image (coool!) and others open the Seaside walkback page. There, if I press debug....

Okay, I brought up seaside using the zinc adaptor and went to the http://localhost:4343/tests/functional/WAFlowErrorFunctionalTest page and click on `Raise Error link and I get a Seaside stack in the web browser ... When I click on the Debug link I get a walkback opened in my client ... So let's see if that works for you ..

No, that didn't work :(  When I click on "Raise Errror" I got this error in the GemClient (after choose to debug GemStone)

  a InternalError occurred (error 2261), The object with object ID 314242817 is corrupt. Reason: ' at offset 1, FetchPosSmallInt_ bad value'

I'll have to look into this one ...  Do you have a stack associated with this error? Any additional information would be useful to get to the bottom of this ...

I tried to recover some old backups, same error. I tried started from a backup that only had glass and gemstone, so I installed JUST seaside and zinc, same problem. 

I am using 3.1.0.4. 

It is very likely that this particular error is referring to a corruption within the temp obj space of the gem and not persistent corruption ... You can run an object audit (see system admin guide) to determine if the persistent repository is corrupt

 

When the  debbuger opens up directly in GemTools, that means that you have a hit an error that is outside the Seaside "application stack" which means that it is a Seaside infrastructure error or a Zinc error (or whatever web server you happen to be using) ... When the debug stack shows up in the web browser, that means you have hit an error that is within your seaside application and the seaside error handling facility is invoked ... you have a number of options for dealing with Seaside errors in GemStone[1]. Each of the different error handlers has different characteristics ...

The set handler field on the Error page tells you which error handler you are currently using, so I will be interested to know which one is set for you.

OK, both (my app and the tests) were using the WARemoteDebuggingWalkbackErrorHandler. But...from what I read in the provided link, I think I should be using WAWalkbackErrorHandler since I launched the gem from GemClient and not topaz, right?

Yes, if you want to be able to debug and proceed from errors, then you should use WAWalkbackErrorHandler, although the WARemoteDebuggingWalkbackErrorHandler is smart enough to recognize that you are running from GemTools (you would get a `Remote Debug` link from topaz) ...

Another question....maybe weird.... when I launch zinc like this: 

(WAGsZincAdaptor port: 8888) start.

I do it as a "do it" in the GemClient workspace. When I do that, the UI is not responsive anymore and the gemstone cursor appears. It only goes away when I manually interrupt it of i a debugger comes. When that happens... the zinc server is down!!  So I have to re-start zinc after each debug? I can imagine that maybe this is because Zinc was started from a Gem or something in my GemClient and when I interrupt that I might be kick off or something and cleans what I did...

So I wonder, is this the correct way to run the web adaptor?  Or I have to run the adaptor inside a transaction (so that I could remain after):

MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [

(WAGsZincAdaptor port: 8888) start.

]

Read the section about GemStone Processes and GCI[1] and then the following section[2] (SOAP/HTTP Server Developement Tips) for tips on working with server processes from GemTools.

[1] http://gemstonesoup.wordpress.com/2009/04/15/glass-beta-update-working-with-soap-preview/#GsProcesses
[2] http://gemstonesoup.wordpress.com/2009/04/15/glass-beta-update-working-with-soap-preview/#soaphttpdev

 

If the debugger opens correctly from the error page, then I'll need to learn more about your specific error that causes the hang ...

OK, thanks for the explanation. I was aware of the error handlers, but I didn't know there were some specific for GemStone :)

 

[1] https://code.google.com/p/glassdb/wiki/Seaside30ErrorHandlers

the GemClient hungs. I can interrupt GemStone but nothing happens. And after sime time I get a 

 'Network error - text follows: , from GciAstFailureNetwork partner has disconnected.'

There might actually be a crash involved here and it is worth checking the gem log file for errors ... you should be able to find the gem log in /opt/gemstone/log ... look at the most recent gemnet*.log file and see if there is an error stack there ...

wow....now I retried everything (recovering from the SAME backup) and now it works (the debug form the tests)....So I don't get it. 

What is worst.... it works (it opens a debugger in GemStone), and I am using the report handler, which, from https://code.google.com/p/glassdb/wiki/Seaside30ErrorHandlers

I understand is not the one I should be using. I understood that handler would store the stuff in the objectlog...but I got a debugger in GemClient.

I am suspicious that there might be a vm bug involved here ... the Internal Error might manifest itself in different ways ... There were a number of process-related bugs that were fixed in 3.1.0.4 (and there still might be one or two more bugs lurking and fixed in 3.1.0.5 ... coming soon) that could  be triggered by the process handling in Zinc ...

If you hit things like this again, I would love to see the log files for the gems (you might actually have some log files lying around already and if you do I would like you to send them to me)...

Dale