Am 04.09.2013 um 11:41 schrieb Esteban Lorenzano <esteba...@gmail.com>:
> > 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? No, I didn't look at that. So nothing to say. Norbert > 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 >>>> >>> >>> >> >> > >
