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

Thu Nov 14 13:27:53 PST 2013

----- Original Message -----

| From: "Mariano Martinez Peck" <marianopeck at gmail.com>
| To: "Dale K. Henrichs" <dale.henrichs at gemtalksystems.com>
| Cc: glass at lists.gemtalksystems.com
| 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 <
| dale.henrichs at gemtalksystems.com > wrote:

| | | From: "Mariano Martinez Peck" < marianopeck at gmail.com >
| | 
| 
| | | To: glass at lists.gemtalksystems.com
| | 
| 
| | | 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131114/4edddcf1/attachment.html>