On 14 January 2013 16:32, Ken Causey ken@kencausey.com wrote:
On 01/14/2013 07:24 AM, David T. Lewis wrote:
Good idea to add a watchdog timer. Another good practice is to use the 'nice' command (/usr/bin/nice) in the command lines that run Squeak. This runs the tests at lower scheduling priority, so if a process gets stuck consuming close to 100% cpu, it impact on other system users will be reduced (it will still gobble up all the cpu, it just won't drag the system down so badly).
I don't know what the problem was in this particular case, but one thing that can result in Squeak consuming 100% is an error in the image that causes too much memory usage, such as a recursion error. Squeak keeps asking for more memory, the VM asks the OS for more, and eventually you are swapping. If this turns out to have been the problem, you can prevent the runaway memory condition with the '-memory' command line option to the VM (but don't do that unless we can confirm that it really *is* the problem, I'm just mentioning it for future reference).
Dave
I could be misunderstanding but I don't think this is it. From the ps output: '1054380 24552'. These are respectively the VSZ (kbytes, virtual memory size) and RSS (kilobytes, resident set size). The relevant number being the second and which is really quite low for a Squeak process, while still being within the expected range of course.
Ken
I looked at what logging _is_ in place in that script, and we're not even hitting the tests themselves. We're hanging during this: FileDirectory default fullNameFor: 'HudsonBuildTools.st'
in tests.st.
frank