Problem solved. (Well, sort of.) I tracked it down to the JPEG VM plug-in. If instead the Smalltalk JPEGReadWriter is used, the problem does not occur. I'm not sure why it only occurs when a Delay is used though.
Then I discovered that it does not occur in Pharo 1.1.1 either (I was using Pharo 1.1.) So something must have changed for the better between the versions. So my problem is solved and I have another reason to always use the latest Pharo version ;) Thanks for your time. TF On Tue, Dec 14, 2010 at 10:56 AM, Stéphane Ducasse < [email protected]> wrote: > thanks > We will have to have alook at semaphore and other.... > > stef > > On Dec 14, 2010, at 7:08 PM, Tony Fleig wrote: > > > In case anybody is interested in this... > > > > I added logging to an external file and found that the hang or crash > > always occurs during the delay. > > > > I removed the Delay from the loop and the problem disappeared. (I'm > > sure glad I have a multi-CPU system though, as it ramped one CPU up to > > 100%.) > > > > I conclude that this is not an image processing related problem, but > > actually a problem with Delay or semaphores or scheduling in Pharo. > > > > I'm continuing my efforts to narrow the problem down. > > > > TF > > > > On Mon, Dec 13, 2010 at 2:19 PM, Tony Fleig <[email protected]> > wrote: > >> I tried using the following background changer for Pharo (from > >> > http://book.pharo-project.org/book/CustomizingPharo/PuttingABackgroundPicture > ). > >> All was well and it nicely changed the background image to various > >> images from socwall.com. I walked away and when I came back, Pharo was > >> no longer running. > >> > >> To make a long story short, on Linux and OS X (I did not try Windows), > >> after some period of time, regardless of whether I am actively using > >> Pharo, Pharo either hangs (becomes unresponsive to input, using 100% > >> CPU, images no longer changing) or disappears abruptly. I tried > >> several variations of the script, including loading images from a > >> local directory (i.e. no network code at all) and even loading images > >> into an ImagePreview morph. > >> > >> In all cases, Pharo eventually either aborts or hangs. I have found > >> nothing in the logs to indicate what happened -- no entries at the > >> time of the abort or hang at all. Decreasing the delay seems to make > >> it happen sooner; I can usually make it happen within 15 minutes of > >> execution with a 2 second delay. It seems to happen more quickly when > >> changing the background image than in an ImagePreview morph. > >> > >> I monitored Pharo's memory usage and it increased from 106 MB to 109 > >> MB during the execution. Plenty of free memory on the system. > >> > >> My questions are: > >> > >> 1. How to debug this? Log to a file to see where it is hanging? > >> > >> 2. How to regain control of a hung Pharo. I tried Cmd-<everything> to no > avail. > >> > >> 3. Does anyone have any idea what might be happening? Some resource > >> being used up, a race condition, etc.? > >> > >> Here's the original script > >> > >> [[[ > >> | rx str url form | > >> str := (HTTPSocket httpGet: > >> 'http://www.socwall.com/browse/index.php?wpLimit=1&wpSortby=8') > >> contents. > >> rx := '.*(http\://.+tb_.+\.jpg).*' asRegex. > >> url := (rx matches: str) > >> ifTrue: > >> str := (rx subexpression: 2) > >> copyWithRegex: 'tb_' matchesReplacedWith: '' ] > >> ifFalse: [ nil ]. > >> url ifNotNil: [ > >> form := ImageReadWriter formFromStream: (HTTPSocket httpGet: url). > >> World backgroundImage: form layout: #scaled]] on: Error do: [:ex| ]. > >> 1 minute asDelay wait ] repeat ] newProcess > >> name: 'Random background changer'; > >> priority: Processor userBackgroundPriority; > >> resume > >> > >> > >> Regards, > >> TF > >> > > > > >
