On Sep 4, 2013, at 11:03 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> > 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. yes, but I cannot reproduce it. It is workign perfectly fine in my machine and my 2 virtual machines with windows and linux. I will like to know which vm version are you using. Esteban > >> 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 >>>> >>>> >>> >>> >> >> > >
