[Glass] How to remote debug exceptions caused by seaside rendering?

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Fri Apr 24 11:31:42 PDT 2015


Glad to help ... ... the stack in frame 97 was an argument or temp of 
frame97, so the process that the debugger opened on was not the process 
that you wanted to debug from the object log and you wouldn't have seen 
that stack in the debugger no matter how many frames you were looking at 
at once ...

Whatever is going wrong is related to the fact that the process that was 
supposed to be debugged was not the one the debugger was opened on and 
that's the initial focus for solving this puzzle ...

I've submitted a bug[1] to track this ... I do want to get to the bottom 
of this, but I've got other fish to fry at the moment:)

Dale

[1] https://github.com/GsDevKit/Seaside31/issues/73

On 04/24/2015 10:25 AM, Mariano Martinez Peck wrote:
>
>
> On Fri, Apr 24, 2015 at 2:01 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>     In frame 97 I came across this printString for a GsProcess and it
>     looks like this guy might be the "droid" you are looking for:).
>
>
> Thanks Dale for the find. I was wondering why I didn't see it myself.. 
> and the answer is that the debugger opened only shows a part of the 
> stack. To attach you the stack I clicked on "copy stack". I thought it 
> was the same I was seeing in the debugger..but it isn't. It's the real 
> full stack.
> So at least I have the dead text stack to analyze.  WTF that the 
> debugger doesn't have a "full stack" button so that at least I can 
> debug a live stack. I know I know ... i should use tODE :)
>
>     From the looks of things it looks like the "normal" seaside object
>     log continuation logic is being used, so I will have to dig deeper
>     to understand what's happening ... if the following stack gets you
>     going again, I might delay looking into this problem a bit,
>     because I'm a bit buried at the moment ...
>
>
> Thanks Dale, the stack below does help me to solve this particular issue.
>
>     Dale
>
>     [97] TransientRecursionLock >> critical: (envId 0)
>         aBlock: anExecBlock
>         proc: GsProcess(oop=16012850177, status=debug, priority=4,
>     WARemoteDebuggingWalkbackErrorHandler >> open: (envId 0) @10 line 10
>     WAWalkbackErrorHandler >> handleDefault: (envId 0) @2 line 2
>     WAErrorHandler >> handleError: (envId 0) @2 line 2
>     WAErrorHandler >> handleGemStoneException: (envId 0) @4 line 4
>     WAGemStoneWalkbackErrorHandler >> handleException: (envId 0) @2 line 2
>     [] in  WAExceptionHandler >> handleExceptionsDuring: (envId 0) @2
>     line 5
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     [] in  WAExceptionHandler >> handleExceptionsDuring: (envId 0) @2
>     line 8
>     [] in  ExecBlock >> on:do: (envId 0) @4 line 49
>     AbstractException >> _executeHandler: (envId 0) @3 line 8
>     AbstractException >> _signalWith: (envId 0) @1 line 1
>     AbstractException >> signal (envId 0) @2 line 47
>     Object >> doesNotUnderstand: (envId 0) @9 line 10
>     Object >> _doesNotUnderstand:args:envId:reason: (envId 0) @7 line 12
>     FaQuandlSF1StocksFundamentalsDBPopulator >>
>     fillExtraInfoFromSeriesToSecurity: (envId 0) @16 line 12
>     FaQuandlDirectDownloadDataAccessor >>
>     getSF1SecurityForTicker:date: (envId 0) @11 line 23
>     FaQuandl >> fill:withSecurityInfoWith:date: (envId 0) @7 line 5
>     FaQuandl >>
>     newQuandlDataEntityByTickerSymbol:viewSampleDates:andAccessorSpec:
>     (envId 0) @17 line 13
>     FaQuandl >> newQuandlDataEntityByTickerSymbol:viewSampleDates:
>     (envId 0) @2 line 2
>     FaQuandl >>
>     getQuandlDataProcessorProxyAt:withSampleDates:withAnalystSpec:
>     (envId 0) @9 line 9
>     FaQuandl >>
>     getQuandlDataProcessorProxyOnAnnualDataAt:withSampleDates: (envId
>     0) @2 line 3
>     FaFnDataResourceRetriever >> dataSource:at: (envId 0) @17 line 15
>     [] in  FaFnDataResourceRetriever >>
>     processorCreateFor:sourceSpec:andAnalystConfigSpec: (envId 0) @5
>     line 19
>     SequenceableCollection >> collect: (envId 0) @9 line 16
>     FaFnDataResourceRetriever >>
>     processorCreateFor:sourceSpec:andAnalystConfigSpec: (envId 0) @12
>     line 17
>     FaFnDataResourceRetriever >>
>     processorAt:sourceSpec:usingAnalystConfig: (envId 0) @2 line 8
>     FaFnDataAccessor >> processorAt:sourceSpec:usingAnalystConfig:
>     (envId 0) @3 line 2
>     FaFnDataReportGeneratorV2 >>
>     processorAt:sourceSpec:usingAnalystConfig: (envId 0) @3 line 7
>     DpNewFnSeriesProcessorReportQuery >> processor (envId 0) @22 line 10
>     DpNewFnSeriesProcessorReportQuery >> getReport (envId 0) @4 line 6
>     [] in  DpNewFnSeriesProcessorReportQuery >> renderButtonsOn:
>     (envId 0) @4 line 13
>     [] in  JSObject >> script:on: (envId 0) @8 line 12
>     [] in  WARenderContext >> document:during: (envId 0) @3 line 6
>     ExecBlock >> ensure: (envId 0) @2 line 12
>     WARenderContext >> document:during: (envId 0) @3 line 7
>     JSObject >> script:on: (envId 0) @7 line 8
>     [] in  JQAjax >> script: (envId 0) @10 line 10
>     WARequestContext >> respond: (envId 0) @3 line 4
>     [] in  JQAjax >> respond: (envId 0) @3 line 4
>     JQAjax >> processCallback (envId 0) @4 line 3
>     [] in  JQAjax >> enableCallbacks (envId 0) @2 line 6
>     ExecBlock >> valueWithPossibleArguments: (envId 0) @6 line 4
>     JSAjaxCallback >> evaluateWithArgument: (envId 0) @5 line 3
>     WACallback >> evaluateWithFieldValues: (envId 0) @4 line 2
>     [] in  WACallbackRegistry >> handle: (envId 0) @4 line 10
>     Collection >> do: (envId 0) @5 line 10
>     WACallbackRegistry >> handle: (envId 0) @9 line 9
>     WACallbackProcessingActionContinuation >> basicPerformAction
>     (envId 0) @6 line 3
>     [] in  WAActionPhaseContinuation >> performAction (envId 0) @2 line 2
>     ExecBlock >> onException:do: (envId 0) @2 line 66
>     ExecBlock >> on:do: (envId 0) @5 line 47
>     WAExceptionHandler >> handleExceptionsDuring: (envId 0) @2 line 3
>     [] in  WARenderLoopContinuation >> withNotificationHandlerDo:
>     (envId 0) @2 line 20
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     WARenderLoopContinuation >> withNotificationHandlerDo: (envId 0)
>     @8 line 21
>     WAActionPhaseContinuation >> performAction (envId 0) @2 line 2
>     [] in  WACallbackProcessingActionContinuation >> performAction
>     (envId 0) @2 line 3
>     ExecBlock >> ensure: (envId 0) @2 line 12
>     WACallbackProcessingActionContinuation >> performAction (envId 0)
>     @2 line 3
>     DpCallbackProcessingActionContinuation >> performAction (envId 0)
>     @5 line 4
>     WAActionPhaseContinuation >> handleFiltered: (envId 0) @2 line 2
>     [] in  WARequestHandler >> handle: (envId 0) @3 line 4
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     WADynamicVariable class >> use:during: (envId 0) @2 line 4
>     [] in  WARequestContext >> push:during: (envId 0) @2 line 5
>     ExecBlock >> ensure: (envId 0) @2 line 12
>     WARequestContext >> push:during: (envId 0) @3 line 6
>     WARequestHandler >> handle: (envId 0) @2 line 4
>     [] in  WASessionContinuation >> handle: (envId 0) @2 line 5
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     WASessionContinuation >> withUnregisteredHandlerDo: (envId 0) @2
>     line 3
>     WASessionContinuation >> handle: (envId 0) @4 line 5
>     WASession >> handleFiltered: (envId 0) @20 line 20
>     [] in  WARequestHandler >> handle: (envId 0) @3 line 4
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     WADynamicVariable class >> use:during: (envId 0) @2 line 4
>     [] in  WARequestContext >> push:during: (envId 0) @2 line 5
>     ExecBlock >> ensure: (envId 0) @2 line 12
>     WARequestContext >> push:during: (envId 0) @3 line 6
>     WARequestHandler >> handle: (envId 0) @2 line 4
>     WASession >> handle: (envId 0) @10 line 11
>     WARegistry >> dispatch:to:key: (envId 0) @4 line 6
>     WARegistry >> handleKeyed:with:context: (envId 0) @2 line 5
>     WARegistry >> handleFiltered: (envId 0) @15 line 13
>     WAApplication >> handleFiltered: (envId 0) @10 line 8
>     WARequestFilter >> handleFiltered: (envId 0) @3 line 4
>     [] in  FaCurrentUserContextInformationFilter >> handleFiltered:
>     (envId 0) @2 line 4
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     WADynamicVariable class >> use:during: (envId 0) @2 line 4
>     FaCurrentUserContextInformationFilter >> handleFiltered: (envId 0)
>     @3 line 3
>     WARequestFilter >> handleFiltered: (envId 0) @3 line 4
>     [] in  WAExceptionFilter >> handleFiltered: (envId 0) @2 line 7
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     WADynamicVariable class >> use:during: (envId 0) @2 line 4
>     [] in  WAExceptionFilter >> handleFiltered: (envId 0) @2 line 6
>     ExecBlock >> onException:do: (envId 0) @2 line 66
>     ExecBlock >> on:do: (envId 0) @5 line 47
>     WAExceptionHandler >> handleExceptionsDuring: (envId 0) @2 line 3
>     WAExceptionFilter >> handleFiltered: (envId 0) @5 line 4
>     [] in  WARequestHandler >> handle: (envId 0) @3 line 4
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     WADynamicVariable class >> use:during: (envId 0) @2 line 4
>     [] in  WARequestContext >> push:during: (envId 0) @2 line 5
>     ExecBlock >> ensure: (envId 0) @2 line 12
>     WARequestContext >> push:during: (envId 0) @3 line 6
>     WARequestHandler >> handle: (envId 0) @2 line 4
>     WADispatcher >> handleFiltered:named: (envId 0) @3 line 5
>     WADispatcher >> handleFiltered: (envId 0) @8 line 6
>     [] in  WARequestHandler >> handle: (envId 0) @3 line 4
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     WADynamicVariable class >> use:during: (envId 0) @2 line 4
>     [] in  WARequestContext >> push:during: (envId 0) @2 line 5
>     ExecBlock >> ensure: (envId 0) @2 line 12
>     WARequestContext >> push:during: (envId 0) @3 line 6
>     WARequestHandler >> handle: (envId 0) @2 line 4
>     [] in  WAServerAdaptor >> handleRequest: (envId 0) @3 line 4
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     WAServerAdaptor >> handleRequest: (envId 0) @2 line 5
>     WAServerAdaptor >> handle: (envId 0) @2 line 4
>     [] in  WAServerAdaptor >> process: (envId 0) @2 line 6
>     ExecBlock >> ensure: (envId 0) @2 line 12
>     WAServerAdaptor >> process: (envId 0) @4 line 7
>     [] in  WAFastCGIAdaptor >> process: (envId 0) @2 line 6
>     [] in  GRGemStonePlatform >>
>     seasideProcessRequestWithRetry:resultBlock: (envId 0) @2 line 11
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     [] in  GRGemStonePlatform >>
>     seasideProcessRequestWithRetry:resultBlock: (envId 0) @11 line 12
>     ExecBlock >> ensure: (envId 0) @2 line 12
>     TransientRecursionLock >> critical: (envId 0) @11 line 12
>     GRGemStonePlatform >> seasideProcessRequestWithRetry:resultBlock:
>     (envId 0) @3 line 5
>     [] in  GRGemStonePlatform >>
>     seasideProcessRequest:adaptor:resultBlock: (envId 0) @6 line 9
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     GRGemStonePlatform >> seasideProcessRequest:adaptor:resultBlock:
>     (envId 0) @2 line 17
>     WAFastCGIAdaptor >> process: (envId 0) @3 line 4
>     [] in  WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 4
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     WAFastCGIAdaptor >> answerResponderRole: (envId 0) @2 line 5
>     FSResponderRole >> answer (envId 0) @3 line 4
>     FSRole >> handleConnection (envId 0) @3 line 5
>     FSConnection >> unsafeServe (envId 0) @5 line 8
>     [] in  FSConnection >> safeServe (envId 0) @2 line 8
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     [] in  FSConnection >> safeServe (envId 0) @2 line 9
>     ExecBlock >> on:do: (envId 0) @3 line 42
>     [] in  FSConnection >> safeServe (envId 0) @2 line 12
>     ExecBlock >> ensure: (envId 0) @2 line 12
>     FSConnection >> safeServe (envId 0) @2 line 15
>     FSConnection >> serve (envId 0) @2 line 4
>     [] in  FSSocketServer >> listen: (envId 0) @3 line 15
>     GsProcess >> _start (envId 0) @7 line 16
>     GsNMethod class >> _gsReturnToC (envId 0) @1 line 1
>     )
>         self: aTransientRecursionLock
>         .t1: anExecBlock
>         .t2: anExecBlock
>         receiver: aTransientRecursionLock
>
>
>
>     On 04/24/2015 09:48 AM, Mariano Martinez Peck wrote:
>>
>>     On Fri, Apr 24, 2015 at 1:40 PM, Dale Henrichs via Glass
>>     <glass at lists.gemtalksystems.com
>>     <mailto:glass at lists.gemtalksystems.com>> wrote:
>>
>>         Mariano,
>>
>>         Debugging the ajax calls is a bit problematic because the
>>         ajax response is in XML and arbitrary xml (which is what is
>>         done for the html debugger) is not an acceptable response ...
>>
>>         Anyway ... I would like to see more of the error stack
>>         specifically the first couple of frames of the process.
>>
>>         When the debugger is being opened on an error continuation,
>>         we basically `execute` the continuation using #debug as the
>>         value. The error handling code inserts code that opens a
>>         debugger when the value is #debug and voila the debugger is
>>         opened.
>>
>>         In your particular case it LOOKS like the continuation was
>>         put into the object log without the special debug code and
>>         the error you are getting is the result of `executing` the
>>         continuation without the benefit of the proper session
>>         handlers wrapped around...
>>
>>         BUT, I need to see the full stack or at the least the bottom
>>         of the stack to confirm ...
>>
>>
>>     Ok, thanks for the explanation. I attach the full stack.
>>
>>         Finally, could you point me to the code where the ajax
>>         handler resides? It's been a while since I've been in that
>>         part of the code and frankly I recall that there was a
>>         problem with error handling for ajax, but I don't  recall
>>         actually doing anything about it ... so a pointer will help
>>         ... if I don't find what I think I am looking for:)
>>
>>
>>     I invoke my ajax handler this way:
>>
>>
>>     html document
>>                     addLoadScript:
>>                             (html jQuery document
>>     onAjaxError: (self ajaxErrorHandler asFunction: #('event' 'jqxhr'
>>     'settings' 'exception'))).
>>
>>
>>     And #ajaxErrorHandler looks like this:
>>
>>
>>     ajaxErrorHandler
>>             ^ ' if (jqxhr.status == 403) {
>>                 alert("For security reasons we sign people out during
>>     periods of inactivity. Please sign in again.");
>>                 window.location.href =
>>     settings.url.split("?")[0].replace("help","");
>>             } else {
>>
>>     // This is on purpose because sometimes with TinyMCE we would get
>>     status 0 and empty error...when there was no error
>>     // The reason is explained in:
>>     http://bartwullems.blogspot.com.ar/2012/02/ajax-request-returns-status-0.html
>>     if (jqxhr.readyState == 0 || jqxhr.status == 0) {
>>        return; //Skip this error
>>     };
>>
>>     // Lets write to console all error info possbile
>>      var requestResponse = {
>>        url: settings.url,
>>        method: settings.type,
>>        data: settings.data,
>>        httpStatus: jqxhr.status,
>>        error: exception || jqxhr.statusText,
>>        data: settings.data
>>      };
>>
>>     console.error(requestResponse);
>>
>>                 alert("This program just broke. You can either try
>>     again, sign out and sign in and try again, or contact us about
>>     error: " + exception);
>>
>>             }'
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>         Dale
>>
>>
>>         On 04/24/2015 08:45 AM, Mariano Martinez Peck via Glass wrote:
>>>         Hi guys,
>>>
>>>         I think that at some point this worked for me... but it
>>>         doesn't anymore...  I have a seaside app and it is using the
>>>         WAGemsToneWalkbackErrorHandler. I have an ajax request  that
>>>         it seems to be causing a walkback. Since it is an ajax call,
>>>         I do not even receive the walkback page where it shows the
>>>         stack and I have the buttons "remote debug", "full stack" ,
>>>         etc. Instead.... I have a new entry in the Object Log. In
>>>         other words, in GemTools I go to "Debug" and I see the
>>>         exception there. THERE in the list, I can see the real
>>>         error..for example "MessageNotUnderstood ocurred (error
>>>         2010), a Set does not undersntand #'on:'". However, when I
>>>         click in the exception so that to open a debugger, the
>>>         debugger cannot open the stack because it always fails to
>>>         get the Seaside context (#session answers nil and therefore
>>>         I get another new MNU about this). See attached screenshot.
>>>
>>>         So... the questions is:
>>>
>>>         1) In the ideal world, I would like to debug it.
>>>         2) If I am not in the ideal world, then at least I would
>>>         like to see the stack of the exception. Right now I cannot
>>>         see ANYTHING... all I know is Set dnu #on:   so yeah,
>>>         probably a class I don't have a in GemStone that is getting
>>>         a class side #on:
>>>
>>>         Any idea how can I make this to work?
>>>
>>>         ps: I have native code enabled. This is in a CentOS machine.
>>>         I am using latest GemStone 3.1 and latest Seaside.
>>>
>>>
>>>
>>>         -- 
>>>         Mariano
>>>         http://marianopeck.wordpress.com
>>>
>>>
>>>         _______________________________________________
>>>         Glass mailing list
>>>         Glass at lists.gemtalksystems.com  <mailto:Glass at lists.gemtalksystems.com>
>>>         http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>         _______________________________________________
>>         Glass mailing list
>>         Glass at lists.gemtalksystems.com
>>         <mailto:Glass at lists.gemtalksystems.com>
>>         http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>
>>
>>     -- 
>>     Mariano
>>     http://marianopeck.wordpress.com
>
>
>
>
> -- 
> Mariano
> http://marianopeck.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150424/70cfca3e/attachment-0001.html>


More information about the Glass mailing list