I'm getting this error when a user attempts to log into a Seaside application. This webapp otherwise works fine on my local Pharo install, and until recently on Gemstone as well. No stack trace or Object Log entry or anything in Gemstone's various fastcgi logs that's helpful.
InterpreterError 2021: A reference into the dictionary <aSessionTemps( #'WA_SERVER_MANAGER_DEFAULT'->aWAServerManager, #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier, #'GsPackage_TransactionBoundary_Dict'->aSessionTemps( #'SessionMethodChange'->2125, #'ClassChange'->7074), #'Monticello-Dependents'->aDictionary( aJ2ModelVendor->anArray( aJ2ModelUser), aJ2ModelFacility->anArray( aJ2ModelUser)), #'GRGemStoneRandomProvider_MUTEX'->aTransientMutex, #'GRGemStoneRandomProvider_GENERATOR'->aTransientRandom, #'Monticello-Transients'->aDictionary( #the Object logs.thing in 'UUID_DEFUALT'->anUUIDGenerator), #'TransientValue'->anIdentityKeyValueDictionary( aTransientValue->nil, aTransientValue->nil, aTransientValue->nil, aTransientValue->nil, aTransientValue->nil, aTransientValue->nil, ...), ...)> using the non-existent key <#'browse'> was made. The details of what the session temps dictionary contains change after I restarted the seaside gems, but it's always the non-existent "browse" key error that turns up. Here's another listing: InterpreterError 2021: A reference into the dictionary <aSessionTemps( #'WA_SERVER_MANAGER_DEFAULT'->aWAServerManager, #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier, #'GsPackage_TransactionBoundary_Dict'->aSessionTemps( #'SessionMethodChange'->2125, #'ClassChange'->7074), #'Monticello-Dependents'->aDictionary( ), #'GRGemStoneRandomProvider_GENERATOR'->aTransientRandom, #'Monticello-Transients'->aDictionary( #'UUID_DEFUALT'->anUUIDGenerator), #'TransientValue'->anIdentityKeyValueDictionary( aTransientValue->nil, aTransientValue->GsProcess(oop=715001857, status=waiting on a socket read event, priority=15, group=1, ProcessorScheduler | _switchFrom:to: @2 line 6 ProcessorScheduler | _reschedule @10 line 15 ProcessorScheduler | _waitUntil:timeout:type: @10 line 14 ProcessorScheduler | _waitUntilReadable:timeout: @2 line 8 GsSocket | readWillNotBlockWithin: @10 line 25 GsSocket | listen:acceptingWith: @9 line 22 GsSocket | accept @4 line 13 [] in FSGsSocketServer | accept:onError: @3 line 6 ExceptionHandler | doTryBlock: @9 line 7 ExceptionHandler | try:on:do: @15 line 18 [] in ExecutableBlock | on:do: @2 line 8 FSGsSocketServer | accept:onError: @4 line 7 FSGsSocketServer (FSSocketServer) | listen: @5 line 7 [] in FSGsSocketServer | startInForeground @7 line 9 [] in ExecutableBlock | ensure: @4 line 11 [] in ExecutableBlock | ensure: @6 line 11 FSGsSocketServer | startInForeground @12 line 12 WAFastCGIAdaptor | basicStart @3 line 3 [] in WAServerManager | start: @5 line 3 [] in ExecutableBlock | ifCurtailed: @4 line 6 [] in ExecutableBlock | ensure: @4 line 11 [] in ExecutableBlock | ensure: @6 line 11 [] in ExecutableBlock | ifCurtailed: @8 line 8 WAServerManager | start: @8 line 4 WAFastCGIAdaptor (WAServerAdaptor) | start @2 line 2 WAFastCGIAdaptor class (WAServerAdaptor class) | startOn: @8 line 10 WAGemStoneRunSeasideGems | startOn: @2 line 3 WAGemStoneRunSeasideGems class | startGemServerOn: @6 line 9 Executed Code @24 line 29 ), ...), ...)> using the non-existent key <#'browse'> was made. Any clues, anyone? I'm suspecting this has something to do with class migration. Speaking of, is their a definitive script available for migrating new deploys of Seaside apps on Gemstone/s? I've just been recompiling my app's package, and sometimes clearing and resetting the root class of my app in the /config web app. (I'm aware of the general instructions in the Gemstone/S programming guide, but haven't read it yet. Yes, I'm sure a great idea! ) -Combi |
Hi Combi,
In a base GLASS image I did a search for methods that included ‘#browse’ and found three of interest: Object>>#'inspect' (uses #'at:otherwise:' so avoids a not-found error) OBGemStonePlatform class>>#'registerBrowseClientForwarder:' (sets the value) OBGemStonePlatform class>>#'handleBrowseRequest:’ (this looks suspicious) If your system has others you will need to investigate them as well. In any case, I notice that the method #’handleBrowseRequest:’ does not check for the key being missing so would generate this error. Presumably the problem is that someone is calling this method when no client forwarder has been registered. A simple test would be to put a halt in that method and then run your application in Pharo. If you hit the breakpoint then this is the code that is triggering the error. Of course, the underlying question is why there is nothing registered to handle it but that may become obvious once you see who is calling the method. From what (little) I know of OB and OT, they seem to be unrelated to Seaside. I have never used them in building moderately complex Seaside applications. In a base image there are two references to this method, from methods in OBBrowser and OTStringHolder. In the base GLASS repository there are no references to either of these globals. James On Mar 2, 2014, at 12:31 PM, combi <[hidden email]> wrote: > I'm getting this error when a user attempts to log into a Seaside > application. This webapp otherwise works fine on my local Pharo install, and > until recently on Gemstone as well. No stack trace or Object Log entry or > anything in Gemstone's various fastcgi logs that's helpful. > > InterpreterError 2021: A reference into the dictionary <aSessionTemps( > #'WA_SERVER_MANAGER_DEFAULT'->aWAServerManager, > #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier, > #'GsPackage_TransactionBoundary_Dict'->aSessionTemps( > #'SessionMethodChange'->2125, #'ClassChange'->7074), > #'Monticello-Dependents'->aDictionary( aJ2ModelVendor->anArray( > aJ2ModelUser), aJ2ModelFacility->anArray( aJ2ModelUser)), > #'GRGemStoneRandomProvider_MUTEX'->aTransientMutex, > #'GRGemStoneRandomProvider_GENERATOR'->aTransientRandom, > #'Monticello-Transients'->aDictionary( #the Object logs.thing in > 'UUID_DEFUALT'->anUUIDGenerator), > #'TransientValue'->anIdentityKeyValueDictionary( aTransientValue->nil, > aTransientValue->nil, aTransientValue->nil, aTransientValue->nil, > aTransientValue->nil, aTransientValue->nil, ...), ...)> using the > non-existent key <#'browse'> was made. > > The details of what the session temps dictionary contains change after I > restarted the seaside gems, but it's always the non-existent "browse" key > error that turns up. Here's another listing: > > > > InterpreterError 2021: A reference into the dictionary <aSessionTemps( > #'WA_SERVER_MANAGER_DEFAULT'->aWAServerManager, > #'SystemChangeNotifier_UniqueInstance'->aSystemChangeNotifier, > #'GsPackage_TransactionBoundary_Dict'->aSessionTemps( > #'SessionMethodChange'->2125, #'ClassChange'->7074), > #'Monticello-Dependents'->aDictionary( ), > #'GRGemStoneRandomProvider_GENERATOR'->aTransientRandom, > #'Monticello-Transients'->aDictionary( #'UUID_DEFUALT'->anUUIDGenerator), > #'TransientValue'->anIdentityKeyValueDictionary( aTransientValue->nil, > aTransientValue->GsProcess(oop=715001857, status=waiting on a socket read > event, priority=15, group=1, ProcessorScheduler | _switchFrom:to: @2 line 6 > ProcessorScheduler | _reschedule @10 line 15 ProcessorScheduler | > _waitUntil:timeout:type: @10 line 14 ProcessorScheduler | > _waitUntilReadable:timeout: @2 line 8 GsSocket | readWillNotBlockWithin: @10 > line 25 GsSocket | listen:acceptingWith: @9 line 22 GsSocket | accept @4 > line 13 [] in FSGsSocketServer | accept:onError: @3 line 6 ExceptionHandler > | doTryBlock: @9 line 7 ExceptionHandler | try:on:do: @15 line 18 [] in > ExecutableBlock | on:do: @2 line 8 FSGsSocketServer | accept:onError: @4 > line 7 FSGsSocketServer (FSSocketServer) | listen: @5 line 7 [] in > FSGsSocketServer | startInForeground @7 line 9 [] in ExecutableBlock | > ensure: @4 line 11 [] in ExecutableBlock | ensure: @6 line 11 > FSGsSocketServer | startInForeground @12 line 12 WAFastCGIAdaptor | > basicStart @3 line 3 [] in WAServerManager | start: @5 line 3 [] in > ExecutableBlock | ifCurtailed: @4 line 6 [] in ExecutableBlock | ensure: @4 > line 11 [] in ExecutableBlock | ensure: @6 line 11 [] in ExecutableBlock | > ifCurtailed: @8 line 8 WAServerManager | start: @8 line 4 WAFastCGIAdaptor > (WAServerAdaptor) | start @2 line 2 WAFastCGIAdaptor class (WAServerAdaptor > class) | startOn: @8 line 10 WAGemStoneRunSeasideGems | startOn: @2 line 3 > WAGemStoneRunSeasideGems class | startGemServerOn: @6 line 9 Executed Code > @24 line 29 ), ...), ...)> using the non-existent key <#'browse'> was made. > > > Any clues, anyone? I'm suspecting this has something to do with class > migration. Speaking of, is their a definitive script available for migrating > new deploys of Seaside apps on Gemstone/s? I've just been recompiling my > app's package, and sometimes clearing and resetting the root class of my app > in the /config web app. (I'm aware of the general instructions in the > Gemstone/S programming guide, but haven't read it yet. Yes, I'm sure a great > idea! ) > > -Combi > > > > -- > View this message in context: http://forum.world.st/opaque-Gemstone-Interpret-2021-error-tp4747370.html > Sent from the Gemstone/S mailing list archive at Nabble.com. > _______________________________________________ > GemStone-Smalltalk mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk _______________________________________________ GemStone-Smalltalk mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk |
Your suspicion was correct. Turns out that an errant "self inspect" debugging statement was buried in my code, which somehow Pharo's Critics Browser "debugging code" rule did not catch. This was what was trying to open up the Omni Browser window.
Thanks for your help. |
Free forum by Nabble | Edit this page |