Am 04.09.2013 um 11:41 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
On Sep 4, 2013, at 10:47 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 04.09.2013 um 01:13 schrieb Esteban Lorenzano <estebanlm@gmail.com>:
On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <pdebruic@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-td47046...) 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-...
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