[Glass] debugging zinc server requests/responses with tode or GemTools
Locked
[Glass] debugging zinc server requests/responses with tode or GemTools
 
|
Hi,
I'm porting some working Pharo code to GemStone. The Zinc server is responding with messages like: a MessageNotUnderstood occurred (error 2010), a UndefinedObject does not understand #'readStream' If I prevent my code from executing it works fine so I think tis something I've done. What I don't know how to do is get more information than whats in the message above. Since I'm not using the Seaside infrastructure I need to figure out how to raise an exception which brings up a debugger. Or prints something to a transcript or dumps a stack into an object log. How can I do that with either tode or GemTools ? Its GemStone 3.1.0.4, on ubuntu 12.04 Thanks Paul _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] debugging zinc server requests/responses with tode or GemTools
|
|
Paul, Option 1 is to run the server in GemTools/tODE ... the client will block, but when you get an error you should be able to bring up a debugger on the GemStone stack to see what is going on ... it's awkward to debug the server running in the client because the client blocks and sometimes it is difficult to interrupt the process and finally if Zinc doesn't do a good job of cleaning up open sockets when you terminate the process then the socket is left open and you have to restart your client to stop the process form listening on the port ... however, this is really the best way to debug infrastructure bugs ...
Hmmm, if the client debugger is not coming up then it is likely that Zinc is catching the error and doing something with the error... I did do some work with Zinc a month or so ago, but I don't recall all of the details, other than I was using tODE and I was getting the debugger to come up so that I could look at the stack ... what I don't remember is whether or not I had to put `self halt` in strategic places (like in the error handling code) ... I also recall that I monkeyed with the logger to do logging to the Transcript/Object log ....
So Option 2 is to use the Object log to trace things ... If you put Transcript shows into your code, the strings are stashed in the object log. If you need more than "simple print statement debugging" then you can collect references to objects in the object log by inserting code like (ObjectLogEntry trace: 'label' object: objectOrArrayofObjectsOfInterest) addToLog ... then you can inspect the object log and see what's going on...
To snap off a continuation you insert code like (DebuggerLogEntry createContinuationLabeled: 'label) addToLog which will drop a continuation rooted in that spot into the object log ... GemTools should allow you to debug these continuations ... with tODE I have to provide a little bit more glue code (I've rewritten the debugger so that you can `attach` to a process so I'll need to tinker with things to let you attach to a continuation)
If the objectlog code is running in a separate vm then you must arrange for a commit to take place and high up in the infrastructure, this means that you will have to insert a commit in places where commits are not normally done ...
There is also code floating around (in the Seaside suport code) that allows you to dump stacks to the gem log and stash a continuation in the object log and conditionally commit ... but if you don't ahve seaside loaded, we'll have to spelunk for that code ...
Dale On Wed, Jan 22, 2014 at 5:49 PM, Paul DeBruicker <[hidden email]> wrote: Hi, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] debugging zinc server requests/responses with tode or GemTools
|
|
In reply to this post by Paul DeBruicker
Hi Paul,
if you use GemTool you can choose the option "popup on debug" from the Admin menus. This should raise a debugger. Sebastian Am 22.01.2014 17:49, schrieb Paul DeBruicker: > Hi, > > I'm porting some working Pharo code to GemStone. The Zinc server is responding with messages like: > > a MessageNotUnderstood occurred (error 2010), a UndefinedObject does not understand #'readStream' > > If I prevent my code from executing it works fine so I think tis something I've done. What I don't know how to do is get more information than whats in the message above. > > Since I'm not using the Seaside infrastructure I need to figure out how to raise an exception which brings up a debugger. Or prints something to a transcript or dumps a stack into an object log. > > > How can I do that with either tode or GemTools ? Its GemStone 3.1.0.4, on ubuntu 12.04 > > > Thanks > > Paul > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass > _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
|
|
In reply to this post by Paul DeBruicker
Any you should set the Zinc server instance debugMode to true ... then
an exception is not cached and the debugger pops up. Marten _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] debugging zinc server requests/responses with tode or GemTools
|
|
Hi guys,
Thanks for the feedback. I got it sorted out. Prior to seeing Marten's advice I changed ZnSingleThreadedServer>>#handleRequestProtected: to: ZnSingleThreadedServer>>#handleRequestProtected: ^ self authenticateAndDelegateRequest: request Which bypassed Zinc's server error handling. I then ran the server from within tODE but the session kept getting disconnected without doing anything. The gem logs from when I was running the server in a Gem (on the same port as in tODE) and restarting it with daemontools showed: '(error 2719) process with this cache name already exists' which would cause a "Fatal Smalltalk Stack Underflow, SEGV in StackLimit page" I was able to track down the Zinc server with the process and 'terminate' it. Once that was done the blocking server in tODE would run and I was able to fix my bugs. So I'm all set. I'm not sure what I did to the server when it was running in the Gem to leave the process hanging around in the Stone. I'll wrap the code I use to start/run the server in an #ensure: to attempt to make sure it stops if things are crashing. and was able to fix my bugs.
|
Re: [Glass] debugging zinc server requests/responses with tode or GemTools
|
|
I'm glad yuu were able to get moving forward again ... additional comment below... On Thu, Jan 23, 2014 at 10:43 AM, Paul DeBruicker <[hidden email]> wrote: Hi guys, This is not right ... The "cache name already exists" error is being generated in response to a call to System class>>cacheName: which was added to the seaside scripts so that the gems could be identified easily in vsd ... probably should bullet proof, that call in the scripts, but a SEGV should not be the result ... could I get the gemlog for the incident so that I can report the bug with a little more detail?
Thanks, Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] debugging zinc server requests/responses with tode or GemTools
|
|
Hi Dale,
At this point I'm not sure what the problem was that caused the SEGV. I think its not the name conflict alone but also that the pre-existing process the new process was conflitctin with was stopped because of a dnu. I'll send you the logs off list from when there was just a name conflict and when there was a dnu. Paul
|
Re: [Glass] debugging zinc server requests/responses with tode or GemTools
|
|
Paul, Thanks for the logs. I see that you are running in 3.1.0.4 and I know that there were a fair amount of process-related bug fixes in 3.1.0.5 ... the system should never segv, but there were some segv issues that were fixed in 3.1.0.5 as well ...
I know that you've cleaned up the bugs that lead to the SEGV, but if you see a SEGV in 3.1.0.5 we'll want to dig deeper ... Dale On Thu, Jan 23, 2014 at 12:53 PM, Paul DeBruicker <[hidden email]> wrote: Hi Dale, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |