Posted by Sven Van Caekenberghe-2 on Aug 23, 2013; 11:21am
URL: https://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-tp4704639p4704764.html


On 23 Aug 2013, at 12:45, Norbert Hartl <[hidden email]> wrote:

> strange but true I have a similar problem as of today. I don't have RFB installed I just installed zinc and use it. I can reproduce the behavior partially:
>
> Opening the image and saving works. Opening, starting a zinc server does as well. But opening, starting the zinc server and issue a request from a browser freezes the image when saving it. If I only issue one request from a browser the image freezes for something between half a minute and a minute. That smells like a timeout problem to me. The issue requested from the browser ends in "self halt" so there is an exception going on. I didn't switch zinc into debugMode for this.
> I wanted to get some more information in the loop by issuing a USR1 signal to the vm when it hangs. But in my case it does not write a dump file into my working directory.
>
> This should be assured behavior that whenever a USR1 signal is received by the vm that it always writes a file? I have plenty of space left on my device.
>
> Norbert

I don't know what is happening, but I just tried something similar in Paul's image:

ZnServer startDefaultOn: 1701
ZnServer default logToTranscript

Open http://localhost:1701/dw-bench in a browser (which keeps the connection open for a while)

Save the image from the World menu, all is OK, with this on the Transcript

2013-08-23 13:14:05 269265 D Executing request/response loop
2013-08-23 13:14:05 269265 I Read a ZnRequest(GET /dw-bench)
2013-08-23 13:14:05 269265 T GET /dw-bench 200 7738B 3ms
2013-08-23 13:14:05 269265 I Wrote a ZnResponse(200 OK text/html;charset=utf-8 7738B)

----SNAPSHOT----an Array(23 August 2013 1:14:19 pm) rfb.image priorSource: 992874

2013-08-23 13:14:19 660707 D Releasing server socket
2013-08-23 13:14:19 660707 I Stopped ZnManagingMultiThreadedServer HTTP port 1701
2013-08-23 13:14:19 660707 D Closing SocketStream[inbuf:4kb/outbuf:16kb]
2013-08-23 13:14:19 269265 D PrimitiveFailed: primitive #primSocketReceiveDataAvailable: in Socket failed while reading request
2013-08-23 13:14:19 269265 D Closing stream
2013-08-23 13:14:19 269265 D Could not remove SocketStream[inbuf:4kb/outbuf:16kb] ignoring

2013-08-23 13:14:19 660707 I Starting ZnManagingMultiThreadedServer HTTP port 1701
2013-08-23 13:14:19 605507 D Initializing server socket

After the save, the number of Processes is OK (one server listener process) and the number of Sockets is OK (the server socket, with its finalization double).

As you can see above, Zn restarts running (managed) servers and tries to close open (worker) connections, swallowing any failures, and eventually cleaning up and recovering.

Now, this is the normal behaviour, maybe something did change somewhere.

Sven