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

[Mariano Martinez Peck]

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 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.



> 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?


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.

]


>  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.

Thanks in advance,

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131114/0b64e791/attachment.html>