On Sep 4, 2013, at 11:03 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 04 Sep 2013, at 10:53, Norbert Hartl <norbert@hartl.name> wrote:
Am 04.09.2013 um 09:14 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 04 Sep 2013, at 08:57, Marcus Denker <marcus.denker@inria.fr> wrote:
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 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-...
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