Is there a debug version of the Dolphin VM or another method to display the
stack of a currently curring VM? In the process of getting the Windows certification I ran into a problem that under some circumstances the Dolphin application eats up 100% CPU time together with one of the SVHOST processes. When I try to reproduce this from the IDE, I just jave to click on another Dolphin window and the problem goes away. Breaking into the code with Ctrl-Break also doesn't show anything interesting and the problem is gone after this also? I already tried the Visual .NET remote debugger, but without debug symbols and without knowledge how to peek into the Smalltalk stack there is no chance to find something out. Then I also tried the APIMON tool from the Windows Resource kit, but this doesn't work with Dolphin for some reason (crash of Dolphin during startup). Regards Carsten Haerle |
Carsten
> Is there a debug version of the Dolphin VM or another method to display the > stack of a currently curring VM? IIRC, OA's answer to this has been "yes, but it would not do you any good" - I must agree, if only because the VM is proprietary except for things (which seems like quite a bit to me) that they are willing to reveal. > In the process of getting the Windows certification I ran into a problem > that under some circumstances the Dolphin application eats up 100% CPU time > together with one of the SVHOST processes. Is the the SVHOST process associated with the certification? If so, it might be a problem unrelated to Dolphin. > When I try to reproduce this from the IDE, I just jave to click on another > Dolphin window and the problem goes away. Breaking into the code with > Ctrl-Break also doesn't show anything interesting and the problem is gone > after this also? Are the certification tests required to reproduce it? One thing that I have done is wire cntl-break to dump callstacks on all threads, and that trick might help you. IIRC, I do that only in runtime sessions. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Bill,
are you willing to share the code snippet? The problem is that I suspect there is some type of deadlock related to the user interface process (even though the application part I am talking about is a GUI-less service). In the IDE I execute the code with "do it", so it it runs in the main thread and I do pumpMessages every once in a while. The interesting part is when the application freezes I just have to activate another IDE window and the application works again? How can this happen? I had several deadlock problems in the past which are related to the way Dolphin works with call-backs. There is a call-back-stack in the VM and the VM ensures that all call-backs have to return in the FILO order (First in last out). Unfortunately it is not possible to see this call-back-stack, and is extremly time consuming to debug these kind of deadlocks without enough information. In most cases it is not neccessary to have a full debug version of the VM. Even then fiddling through all the data strucctures would be quite time consuming, but a little more support for remote debugging would very good. A full remote debugger like in Java and C/C++ or .NET would be the best thing, but I fear this will be out ouf reach (Blair?). A simple debugging feature would the ability to connect the a separate thread running in the VM via a pipe or TCP connection and have some commands like: suspend: stops all smalltalk execution (or even all threads apart from the debugging thread) resume: resume smalltalk execution show processes: shows a list of smalltalk processes show process stack ####: shows the stack of the smalltalk process with number #### including byte code instruction pointer show call-back-stack: shows the external-call-back stack and the association to the smalltalk processes Blair, how about this, or do you already have this kind of utility? Regards Carsten Haerle "Bill Schwab" <[hidden email]> schrieb im Newsbeitrag news:[hidden email]... > Carsten > > > Is there a debug version of the Dolphin VM or another method to display > the > > stack of a currently curring VM? > > IIRC, OA's answer to this has been "yes, but it would not do you any good" - > I must agree, if only because the VM is proprietary except for things (which > seems like quite a bit to me) that they are willing to reveal. > > > > In the process of getting the Windows certification I ran into a problem > > that under some circumstances the Dolphin application eats up 100% CPU > time > > together with one of the SVHOST processes. > > Is the the SVHOST process associated with the certification? If so, it > might be a problem unrelated to Dolphin. > > > > When I try to reproduce this from the IDE, I just jave to click on > > Dolphin window and the problem goes away. Breaking into the code with > > Ctrl-Break also doesn't show anything interesting and the problem is gone > > after this also? > > Are the certification tests required to reproduce it? One thing that I have > done is wire cntl-break to dump callstacks on all threads, and that trick > might help you. IIRC, I do that only in runtime sessions. > > Have a good one, > > Bill > > -- > Wilhelm K. Schwab, Ph.D. > [hidden email] > > > > |
Carsten,
> are you willing to share the code snippet? See below. Alter it to suit your needs and then invoke it something like this: onUserBreak self dumpAllCallStacks. super onUserBreak > The problem is that I suspect > there is some type of deadlock related to the user interface process (even > though the application part I am talking about is a GUI-less service). If you block the main thread waiting for data from a socket, etc., you might get into trouble. > In the IDE I execute the code with "do it", so it it runs in the main thread > and I do pumpMessages every once in a while. The interesting part is when > the application freezes I just have to activate another IDE window and the > application works again? How can this happen? That could be as simple as providing messages, but since you mention callbacks, I suspect it is more complicated. Re remote debugging, I have had some success with a variant on the code below as part of a TCP server, though I have done nothing beyond the basic call stacks. Have a good one, Bill ----------------------- dumpAllCallStacks "Write a report of the callstacks for all threads." | aStream | [ aStream := FileStream write:self ufLogDirectory, '\threads.log' mode: #append. [ aStream setToEnd; nextPutAll:'=========================================================='; cr; print: TimeStamp current; nextPutAll: ' Threads dump from ', SessionManager current class name asString; cr; nextPutAll:'=========================================================='; cr. ( Process allInstances select:[ :e | e isAlive ] ) do:[ :thread | aStream nextPutAll:thread name displayString; cr; nextPutAll:String lineDelimiter, ( thread stackTrace:thread size ). ] separatedBy:[ aStream cr; nextPutAll:'----------------------------------------------------------'; cr. ]. aStream cr; cr. ] ensure:[ aStream close ]. ] on:Error do:[:e | "Suppress errors writing to log"]. -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Free forum by Nabble | Edit this page |