Smalltalk › Pharo › Pharo Smalltalk Users

RFB on 2.0 + linux - semaphore primitive failed

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

43 messages Options

123

Paul DeBruicker

RFB on 2.0 + linux - semaphore primitive failed

Hi -

In Pharo2 do I need to stop and start the RFB server? I 've been
getting a

primitive #signal in Semaphore failed

error after the image starts. I'm using this version of RFB

RFB-MarianoMartinezPeck.41

Thanks

Paul

Mariano Martinez Peck

Re: RFB on 2.0 + linux - semaphore primitive failed

Maybe this is related to #maxExternalSemaphores: ?

Did you try sending a large number? For my seaside images where I have RFB I do:

Smalltalk vm maxExternalSemaphoresSilently: 65535.

Cheers,

On Wed, Jul 31, 2013 at 3:45 PM, Paul DeBruicker <[hidden email]> wrote:

Hi -

In Pharo2 do I need to stop and start the RFB server? I 've been
getting a

primitive #signal in Semaphore failed

error after the image starts. I'm using this version of RFB

RFB-MarianoMartinezPeck.41

Thanks

Paul

--
Mariano
http://marianopeck.wordpress.com

Paul DeBruicker

Re: RFB on 2.0 + linux - semaphore primitive failed

I don't know. I don't get the errors that used to occur with the max
semaphores being exceeded. I thought Igor Stasenko fixed that issue in
the VM so the array that holds the semaphores grows without blocking.
Or something.

What I do know is that if I 'abandon' that warning and save & quit and
then reopen the image then the UI is locked and I have to use Seaside's
WAScreenshot tool to suspend and resume the UI to unfreeze it.

On 07/31/2013 11:57 AM, Mariano Martinez Peck wrote:

> Maybe this is related to #maxExternalSemaphores: ?
>
> Did you try sending a large number? For my seaside images where I have
> RFB I do:
>
> Smalltalk vm maxExternalSemaphoresSilently: 65535.
>
> Cheers,
>
>
> On Wed, Jul 31, 2013 at 3:45 PM, Paul DeBruicker <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> Hi -
>
> In Pharo2 do I need to stop and start the RFB server? I 've
> been
> getting a
>
> primitive #signal in Semaphore failed
>
> error after the image starts. I'm using this version of RFB
>
> RFB-MarianoMartinezPeck.41
>
> Thanks
>
> Paul
>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com

Igor Stasenko

Re: RFB on 2.0 + linux - semaphore primitive failed

On 31 July 2013 22:17, Paul DeBruicker <[hidden email]> wrote:
> I don't know. I don't get the errors that used to occur with the max
> semaphores being exceeded. I thought Igor Stasenko fixed that issue in
> the VM so the array that holds the semaphores grows without blocking.
> Or something.
>
You can have as big as you want array with semaphores.
There is no limits and maxExternalSemaphoresSilently is just does
nothing and ignored.

>
>
> What I do know is that if I 'abandon' that warning and save & quit and
> then reopen the image then the UI is locked and I have to use Seaside's
> WAScreenshot tool to suspend and resume the UI to unfreeze it.
>
>
weird. i would start from figuring out, why primitive failed..and for
which semaphore.

--
Best regards,
Igor Stasenko.

Paul Wilke

Re: RFB on 2.0 + linux - semaphore primitive failed

In reply to this post by Paul DeBruicker

Hi,
we have a similar problem. Which VM should one use? We had the StackVM in productive use but now after using Pharo 2.0 we have this primitive error and a stuck image. We found one cause in a the netname resolver.

I would greatly appreciate an info about which vm exactly to use or how to further diagnose this problem.
Kind regards,
Paul

Paul DeBruicker

Re: RFB on 2.0 + linux - semaphore primitive failed

Paul Wilke wrote

Hi,
we have a similar problem. Which VM should one use? We had the StackVM in productive use but now after using Pharo 2.0 we have this primitive error and a stuck image. We found one cause in a the netname resolver.

I would greatly appreciate an info about which vm exactly to use or how to further diagnose this problem.
Kind regards,
Paul

I ended up reverting back to Pharo 1.4 and don't have plans to use Pharo 2 in production.

Stéphane Ducasse

Re: RFB on 2.0 + linux - semaphore primitive failed

Hi Paul2

> Paul Wilke wrote
>> Hi,
>> we have a similar problem. Which VM should one use? We had the StackVM in
>> productive use but now after using Pharo 2.0 we have this primitive error
>> and a stuck image. We found one cause in a the netname resolver.

Can you explain what is the netname resolver problem.

>>
>> I would greatly appreciate an info about which vm exactly to use or how to
>> further diagnose this problem.
>> Kind regards,
>> Paul
>
>
> I ended up reverting back to Pharo 1.4 and don't have plans to use Pharo 2
> in production.

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

> --
> View this message in context: http://forum.world.st/RFB-on-2-0-linux-semaphore-primitive-failed-tp4701741p4706301.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

Paul DeBruicker

Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

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.

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.

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.

Hope this helps and thanks for following up

Paul

EstebanLM

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <[hidden email]> 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 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-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.
>
> 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.

Esteban

ps: I would also like to know about other cases of this problem.

>
>
> Hope this helps and thanks for following up
>
>
> Paul
>

EstebanLM

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

On Sep 4, 2013, at 1:13 AM, Esteban Lorenzano <[hidden email]> wrote:

after ESUG, I meant :)

btw, I also have productive environments with RFB running... so I will take a look to that locking image too.

>
>>
>>
>>
>>
>> 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.
>>
>> 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.
>
> Esteban
>
> ps: I would also like to know about other cases of this problem.
>
>>
>>
>> Hope this helps and thanks for following up
>>
>>
>> Paul
>>
>

Marcus Denker-4

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

In reply to this post by Paul DeBruicker

On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <[hidden email]> wrote:

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

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

signature.asc (210 bytes) Download Attachment

Sven Van Caekenberghe-2

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

On 04 Sep 2013, at 08:57, Marcus Denker <[hidden email]> wrote:

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

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

Stéphane Ducasse

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

In reply to this post by Paul DeBruicker

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

Ok I remember. We will have a look.

> 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

Ok.

> I understand this is due to some leaks involving morphs and announcers
> and things that are fixed in pharo 3 but not pharo 2.

Yes igor and esteban spent some times and they are probably some left. ( sadly :)
doing is more difficult than doing nothing)

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

I understand. Thanks for the email.

> Hope this helps and thanks for following up

Yes!

>
>
> Paul
>

EstebanLM

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

In reply to this post by Marcus Denker-4

On Sep 4, 2013, at 8:57 AM, Marcus Denker <[hidden email]> wrote:

I undertand what you want and why do you say that you do not like RFB... but we are still far from the real answer and also people will always load their own third part libraries and that should be possible.
Of course, since they not part of the core libraries, we do not have to take responsibility of those packages (we cannot take responsibility for all packages around)... but problem reported is a VM freeze, and that is of interest for us, so I still will take a look.
Also, as I said... I have RFB running in 2.0 so it shouldn't have problems.

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

I'm not sure what we are seeing in pharo3 is the same problem reported in pharo2.
Of course if it is, we will backport.
But "inflation" problem in ph3 is very consistent and repeatable, the problem reported in ph2... well, I never seen it before, and we have just one report (and I assume that we have more than one hundred production projects with that version).
So is likely something different (also some of the detected leaks are due to changes in ph3, not present in the older version).

Esteban

>
> Marcus
>
>

Marcus Denker-4

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

On Sep 4, 2013, at 9:55 AM, Esteban Lorenzano <[hidden email]> wrote:

>>>
>>>
>> 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
>
> I'm not sure what we are seeing in pharo3 is the same problem reported in pharo2.
> Of course if it is, we will backport.
> But "inflation" problem in ph3 is very consistent and repeatable, the problem reported in ph2... well, I never seen it before, and we have just one report (and I assume that we have more than one hundred production projects with that version).
> So is likely something different (also some of the detected leaks are due to changes in ph3, not present in the older version).
>

Yes, the problem in Pharo2 seems to be related purely to morph extensions hanging around.

https://pharo.fogbugz.com/f/cases/11290/There-are-far-more-instances-of-MorphExtension-than-Morph

(yes, I should have added a parent case for "back port to 2.0").

Marcus

signature.asc (210 bytes) Download Attachment

NorbertHartl

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

In reply to this post by EstebanLM

Am 04.09.2013 um 01:13 schrieb Esteban Lorenzano <[hidden email]>:

>
> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <[hidden email]> 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 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-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.
>>
>> 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

>> Hope this helps and thanks for following up
>>
>>
>> Paul
>>
>
>

NorbertHartl

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

In reply to this post by Sven Van Caekenberghe-2

Am 04.09.2013 um 09:14 schrieb Sven Van Caekenberghe <[hidden email]>:

>
> On 04 Sep 2013, at 08:57, Marcus Denker <[hidden email]> wrote:
>
>>
>> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <[hidden email]> 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
>>
>>
>
>

Sven Van Caekenberghe-2

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

In reply to this post by NorbertHartl

On 04 Sep 2013, at 10:47, Norbert Hartl <[hidden email]> wrote:

> In all my other projects using zinc and RFB I didn't see the problem. But then I don't save images in production.

Images are very cool and very useful, but saving images in production is a no go, it is asking for trouble, IMHO.

Sven

NorbertHartl

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

Am 04.09.2013 um 10:54 schrieb Sven Van Caekenberghe <[hidden email]>:

>
> On 04 Sep 2013, at 10:47, Norbert Hartl <[hidden email]> wrote:
>
>> In all my other projects using zinc and RFB I didn't see the problem. But then I don't save images in production.
>
> Images are very cool and very useful, but saving images in production is a no go, it is asking for trouble, IMHO.
>
That's what I said without making something general out of it ;)

Norbert

Sven Van Caekenberghe-2

Re: Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

In reply to this post by NorbertHartl

On 04 Sep 2013, at 10:53, Norbert Hartl <[hidden email]> wrote:

>
> Am 04.09.2013 um 09:14 schrieb Sven Van Caekenberghe <[hidden email]>:
>
>>
>> On 04 Sep 2013, at 08:57, Marcus Denker <[hidden email]> wrote:
>>
>>>
>>> On Sep 4, 2013, at 12:42 AM, Paul DeBruicker <[hidden email]> 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
>>>
>>>
>>
>>
>
>

123