Am 04.09.2013 um 01:13 schrieb Esteban Lorenzano <esteba...@gmail.com>:
> > On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <pdebr...@gmail.com> wrote: > >> On 09/03/2013 12:25 PM, Stéphane Ducasse wrote: >>> If you do not give us more information we will never be able to fix it. >>> And may be 3.0 will still have the problem and you will start using system >>> that is 3 year old. >>> I can understand that you get in a situation where you cannot do otherwise >>> but do not expect >>> us to fix magically things. >>> >>> Stef >> >> >> Hi Stef, >> >> For reporting the RFB issue I made a thread >> (http://forum.world.st/How-do-diagnose-image-locks-up-cpu-100-on-save-td4704639.html) >> and uploaded a Pharo 2 image to dropbox where if you execute this code: >> >> >> RFBServer start >> Smalltalk snapshot: true andQuit: false >> >> >> The image locks up using the 'pharo' VM and works fine using eliots vm. >> The uploaded image is Pharo-20619 with only RFB loaded. > > I will check this (after SUG) > >> >> >> >> >> The other problem I had with Pharo 2 is the ever growing image size I >> reported here: >> >> http://forum.world.st/development-image-memory-use-180MB-in-Pharo-2-vs-40MB-in-Pharo-1-4-tp4699207.html >> >> I understand this is due to some leaks involving morphs and announcers >> and things that are fixed in pharo 3 but not pharo 2. >> >> I have not gotten the impression that that fix will be backported, and >> even if it will it hasn't been yet so because of that and the RFB issue >> above I can't use Pharo 2 right now. > > this is weird, because is the first time I see a report (well, I saw the > other thread too) about this. > and Pharo2 is productive since more than 8 months now (and I have some > production stuff on it)... and I never seen it. > This is likely not for the same reasons as pharo3 leaks (which btw are just > partially solved, the leaks are still there). > > I would like to have that image to take a look, if possible, because is > super-weird. > >> I reported a similar problem. I'm doing a project for that I need to use zinc, DBXTalk and RFB. Zinc provides a http interface which triggers a database lookup. In my scenario I can save the image until the first request is fired. Every image that will be saved later will bring up an empty window and 100% CPU usage on reopening. I just had some time to track it down. I can see this behavior on my mac laptop as well as on my linux server. I suspected dbxtalk until Paul brought up the RFB case. But I need to spend more time for tracking down the error or producing a reproducable image showing the effect. In all my other projects using zinc and RFB I didn't see the problem. But then I don't save images in production. Norbert >> Hope this helps and thanks for following up >> >> >> Paul >> > >
