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. 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 >> >> > >
