On Sep 4, 2013, at 10:47 AM, Norbert Hartl <norb...@hartl.name> wrote:
> > 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, I was talking about the "inflation" problem in that paragraph, not the RFB hang... can you confirm it? And well, yes RFB+Zinc+DBXTalk can be a combination to look... a lot of FFI/Plugin interaction there (specially if using Zodiac). Esteban > > Norbert > >>> Hope this helps and thanks for following up >>> >>> >>> Paul >>> >> >> > >
