[Pharo-dev] How do diagnose image locks up (cpu 100%) on save?

Paul DeBruicker pdebruic at gmail.com
Thu Aug 22 18:22:37 EDT 2013


Sven Van Caekenberghe-2 wrote
> On 22 Aug 2013, at 19:34, Paul DeBruicker <

> pdebruic@

> > wrote:
> 
>> Hi -
>> 
>> The plain Pharo 20619 + RFB image in my dropbox here:
>> https://dl.dropboxusercontent.com/u/4460862/pharo2RFB.zip freezes when
>> you save it while the RFB server is running.  The freeze occurs in the
>> #snapshotPrimitive.
>> 
>> 
>> This is the VM info I'm using:
>> 
>> 3.9-7 #1 Wed Mar 13 18:22:44 CET 2013 gcc 4.4.3
>> NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
>> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid:
>> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013
>> git://gitorious.org/cogvm/blessed.git Commit:
>> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100
>> By: Esteban Lorenzano <

> estebanlm@

> > Jenkins build #14535
>> Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59
>> UTC 2012 x86_64 GNU/Linux
>> plugin path: /home/paul/pharo/pharo2.0/bin [default:
>> /home/paul/pharo/pharo2.0/bin/]
>> 
>> 
>> How can I diagnose/fix what is going wrong?
>> 
>> 
>> I'm reluctant to make it stop and start the RFB server through the
>> snapshot because it will kick off all attached clients. Of which there
>> is at most one and its me, so it wouldn't be too bad but its not
>> desirable.
>> 
>> It freezes whether there is a client connection or not.
> 
> Paul,
> 
> Zinc HTTP Server are stopped/started on each image save. For HTTP 1.1 that
> is OK, protocol wise. I think that RFB should do something similar to
> prevent issues like the one you are reporting (and there have been many in
> the past as well). 
> 
> Consider this: if you save but do not quit, and you later abort the image
> hard, you would expect the saved image to work, right. That can only be
> with a fresh server socket.
> 
> Sven
> 
>> Thanks
>> 
>> Paul
>>



I think the 'abort the image hard' problem is taken care of in the #startUp:
method on the RFBServer.  It checks if the image is resuming and the server
is/was running and if so stopping then restarting the RFB server.  I don't
want to stop and restart the server every time there is a save.  I'm fine
doing it on startup after a quit or abort as you describe.  

Anyway, from the stack dump I posted I cannot tell for sure but it seems
like a VM bug.  






--
View this message in context: http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-tp4704639p4704689.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.




More information about the Pharo-dev mailing list