Debugversion of Dolphin VM?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugversion of Dolphin VM?

Carsten Haerle
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


Reply | Threaded
Open this post in threaded view
|

Re: Debugversion of Dolphin VM?

Bill Schwab-2
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]


Reply | Threaded
Open this post in threaded view
|

Re: Debugversion of Dolphin VM?

Carsten Haerle
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
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]
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Debugversion of Dolphin VM?

Schwab,Wilhelm K
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]