On 04 Sep 2013, at 10:53, Norbert Hartl <norb...@hartl.name> wrote: > > Am 04.09.2013 um 09:14 schrieb Sven Van Caekenberghe <s...@stfx.eu>: > >> >> On 04 Sep 2013, at 08:57, Marcus Denker <marcus.den...@inria.fr> wrote: >> >>> >>> 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 really do not like RFB… we do not use it at all in the daily development, >>> yet it people >>> load it for production environments. >>> >>> For me, the system we use every day should be identical to the production >>> environment, >>> else it is very hard to get a stable system. >>> >>> (We need to make what people get of of using RFB part of the base system: >>> remote browsing >>> and debugging). >> >> I totally agree: the why use RFB part and the remote browsing/debugging >> replacement part. On the other hand, if people want to use some library, >> that should be possible. >> >> The problem is this case is (again) that have a user (no offence Paul) of >> some external library that says 'I take a stock image + a library and it >> does not work in some specific case: pharo people help me please' while the >> maintainer of RFB is nowhere to be seen or heard of, let alone that he would >> be willing to take responsibility for how his/her software runs on recent >> Pharo image/vm/platform combinations - it _is_ a lot of work to maintain >> open source software. >> >> I looked a little bit at the RFB code: it is pretty OK AFAIKT, but it does >> hackery stuff with networking. And Paul's problem only occurs if you save an >> image with RFB connections open on Linux on a specific VM. It will require >> dedication to debug this.. >> > I agree what you said in general. But my gut tells me that it isn't RFBs > fault triggering the problem. I had the scenario "save image with open RFB > connection" in mind. If you have a linux server and debugging stuff this is > just the case you use. I did examine that. I started the image with a script > that 1 minute later did save and quit. So there was an open RFB server socket > listening but no connect. Doing a http request that triggers a database > lookup (zinc and dbxtalk) within that minute the image goes into 100% CPU > usage on reopening. > > So I wouldn't be so sure it is RFB.
Yeah, I know, but Paul case was just with a stock image/vm + RFB and it was triggered by the image save. Like I said, these things are hard. > Norbert > >> Sven >> >>>> 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. >>>> >>> We are in the process of fixing them, but have not fixed all yet. I always >>> thought that we would >>> back port when we have fixed the problem completely in 3.0 >>> >>> Marcus >>> >>> >> >> > >
