Nautilus memory leak/hog crashing Pharo
Hi, It seems that when even a single Nautilus system browser is open and you do a load (using Metacello), there is a huge amount of objects that get created and persisted in the image. This even leads to the point that the image crashes when I try to load our code using a ConfigurationOf. After some time, the Pharo process is stuck at 100%, image size is over 500MB and the entire image becomes unresponsive, finally crashing after an hour or so. I have not yet found which objects or why, but I just wrestled with this all day to find out what was going on. I first thought that Metacello was in an infinite loop but after noticing that the image was so large (500MB) and that it got reduced to 20% of its size after closing the browser window, I can say that Nautilus is gathering garbage. It is definitely not Metacello because I can trigger the same problem doing a load via Monticello only. When I load the ConfigurationOf without a single browser open, it loads 5x faster and the image size stays reasonable. Is this a known issue? Any thoughts on what may be causing this? regards! Johan
Maybe due to some Annoucement being picked up by Nautilus? Phil On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau <johan@inceptive.be> wrote:
Hi,
It seems that when even a single Nautilus system browser is open and you do a load (using Metacello), there is a huge amount of objects that get created and persisted in the image. This even leads to the point that the image crashes when I try to load our code using a ConfigurationOf. After some time, the Pharo process is stuck at 100%, image size is over 500MB and the entire image becomes unresponsive, finally crashing after an hour or so.
I have not yet found which objects or why, but I just wrestled with this all day to find out what was going on. I first thought that Metacello was in an infinite loop but after noticing that the image was so large (500MB) and that it got reduced to 20% of its size after closing the browser window, I can say that Nautilus is gathering garbage. It is definitely not Metacello because I can trigger the same problem doing a load via Monticello only.
When I load the ConfigurationOf without a single browser open, it loads 5x faster and the image size stays reasonable.
Is this a known issue? Any thoughts on what may be causing this?
regards! Johan
Sorry to ask then, but: would it be possible to profile a configurationOf... load with and without a Nautilus open? Time spent handling announcements should be visible, and, yes, when loading code, Browsers have to be aware the code is being changed. I spent some time optimizing that for AltBrowser, and it can very significantly increase the loading time, without counting in side effects such as over-caching (and I know Nautilus does some caching, but I'm not sure I understand why). Thierry Le 25/06/2014 20:20, phil@highoctane.be a écrit :
Maybe due to some Annoucement being picked up by Nautilus?
Phil
On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau <johan@inceptive.be <mailto:johan@inceptive.be>> wrote:
Hi,
It seems that when even a single Nautilus system browser is open and you do a load (using Metacello), there is a huge amount of objects that get created and persisted in the image. This even leads to the point that the image crashes when I try to load our code using a ConfigurationOf. After some time, the Pharo process is stuck at 100%, image size is over 500MB and the entire image becomes unresponsive, finally crashing after an hour or so.
I have not yet found which objects or why, but I just wrestled with this all day to find out what was going on. I first thought that Metacello was in an infinite loop but after noticing that the image was so large (500MB) and that it got reduced to 20% of its size after closing the browser window, I can say that Nautilus is gathering garbage. It is definitely not Metacello because I can trigger the same problem doing a load via Monticello only.
When I load the ConfigurationOf without a single browser open, it loads 5x faster and the image size stays reasonable.
Is this a known issue? Any thoughts on what may be causing this?
regards! Johan
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory. But yes, I will make a ticket and get some more profiling with that so we can fix it. Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-) cheers Johan On 26 Jun 2014, at 09:47, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Sorry to ask then, but:
would it be possible to profile a configurationOf... load with and without a Nautilus open? Time spent handling announcements should be visible, and, yes, when loading code, Browsers have to be aware the code is being changed.
I spent some time optimizing that for AltBrowser, and it can very significantly increase the loading time, without counting in side effects such as over-caching (and I know Nautilus does some caching, but I'm not sure I understand why).
Thierry
Le 25/06/2014 20:20, phil@highoctane.be a écrit :
Maybe due to some Annoucement being picked up by Nautilus?
Phil
On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau <johan@inceptive.be <mailto:johan@inceptive.be>> wrote:
Hi,
It seems that when even a single Nautilus system browser is open and you do a load (using Metacello), there is a huge amount of objects that get created and persisted in the image. This even leads to the point that the image crashes when I try to load our code using a ConfigurationOf. After some time, the Pharo process is stuck at 100%, image size is over 500MB and the entire image becomes unresponsive, finally crashing after an hour or so.
I have not yet found which objects or why, but I just wrestled with this all day to find out what was going on. I first thought that Metacello was in an infinite loop but after noticing that the image was so large (500MB) and that it got reduced to 20% of its size after closing the browser window, I can say that Nautilus is gathering garbage. It is definitely not Metacello because I can trigger the same problem doing a load via Monticello only.
When I load the ConfigurationOf without a single browser open, it loads 5x faster and the image size stays reasonable.
Is this a known issue? Any thoughts on what may be causing this?
regards! Johan
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 26 Jun 2014, at 15:17, Johan Brichau <johan@inceptive.be> wrote:
I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory.
But yes, I will make a ticket and get some more profiling with that so we can fix it. Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-)
I disagree a bit ;-) Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up. Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower. Like Stéphane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines.
cheers Johan
On 26 Jun 2014, at 09:47, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Sorry to ask then, but:
would it be possible to profile a configurationOf... load with and without a Nautilus open? Time spent handling announcements should be visible, and, yes, when loading code, Browsers have to be aware the code is being changed.
I spent some time optimizing that for AltBrowser, and it can very significantly increase the loading time, without counting in side effects such as over-caching (and I know Nautilus does some caching, but I'm not sure I understand why).
Thierry
Le 25/06/2014 20:20, phil@highoctane.be a écrit :
Maybe due to some Annoucement being picked up by Nautilus?
Phil
On Wed, Jun 25, 2014 at 7:57 PM, Johan Brichau <johan@inceptive.be <mailto:johan@inceptive.be>> wrote:
Hi,
It seems that when even a single Nautilus system browser is open and you do a load (using Metacello), there is a huge amount of objects that get created and persisted in the image. This even leads to the point that the image crashes when I try to load our code using a ConfigurationOf. After some time, the Pharo process is stuck at 100%, image size is over 500MB and the entire image becomes unresponsive, finally crashing after an hour or so.
I have not yet found which objects or why, but I just wrestled with this all day to find out what was going on. I first thought that Metacello was in an infinite loop but after noticing that the image was so large (500MB) and that it got reduced to 20% of its size after closing the browser window, I can say that Nautilus is gathering garbage. It is definitely not Metacello because I can trigger the same problem doing a load via Monticello only.
When I load the ConfigurationOf without a single browser open, it loads 5x faster and the image size stays reasonable.
Is this a known issue? Any thoughts on what may be causing this?
regards! Johan
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit :
On 26 Jun 2014, at 15:17, Johan Brichau <johan@inceptive.be> wrote:
I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory.
But yes, I will make a ticket and get some more profiling with that so we can fix it. Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-)
I disagree a bit ;-)
Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up.
This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)).
Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower.
Not by much.
Like Stéphane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines.
I disagree with you there. Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code. I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating). Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goubier@cea.fr>:
Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit :
On 26 Jun 2014, at 15:17, Johan Brichau <johan@inceptive.be> wrote:
I will do that, but the main problem is not the loading speed.
The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory.
But yes, I will make a ticket and get some more profiling with that so we can fix it. Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-)
I disagree a bit ;-)
Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up.
This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)).
Now, there is probably something wrong, and things can probably be tuned,
but I think this will always be slower.
Not by much.
Like Stéphane said, loading a big batch of code should happen in a
special way, disabling updates and firing a full reset at the end - or something along those lines.
I disagree with you there.
Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code.
I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating).
Thierry
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
I can not reproduce this, neither the crash nor the image memory blow up. I tested several ConfigurationOfXXX, with one or more open Browsers. Can you tell me what Configuration you are trying to load and if this is a fresh pharo image or are there any other packages loaded. And do you have any Nautilus plugins enabled? regards Nicolai
Nicolai, It's not a public configuration and it loads quite some packages. I will pick up this issue this evening to get a better reproducible case. thx Johan On 26 Jun 2014, at 16:03, Nicolai Hess <nicolaihess@web.de> wrote:
2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goubier@cea.fr>:
Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit :
On 26 Jun 2014, at 15:17, Johan Brichau <johan@inceptive.be> wrote:
I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory.
But yes, I will make a ticket and get some more profiling with that so we can fix it. Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-)
I disagree a bit ;-)
Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up.
This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)).
Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower.
Not by much.
Like Stéphane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines.
I disagree with you there.
Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code.
I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating).
Thierry
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
I can not reproduce this, neither the crash nor the image memory blow up. I tested several ConfigurationOfXXX, with one or more open Browsers.
Can you tell me what Configuration you are trying to load and if this is a fresh pharo image or are there any other packages loaded. And do you have any Nautilus plugins enabled?
regards Nicolai
I reported it as bug 13422 [1]. For now, I was only able to do a comparison before/after which instances are being kept around. Johan [1] https://pharo.fogbugz.com/default.asp?13422#104139 On 26 Jun 2014, at 16:33, Johan Brichau <johan@inceptive.be> wrote:
Nicolai,
It's not a public configuration and it loads quite some packages. I will pick up this issue this evening to get a better reproducible case.
thx Johan
On 26 Jun 2014, at 16:03, Nicolai Hess <nicolaihess@web.de> wrote:
2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goubier@cea.fr>:
Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit :
On 26 Jun 2014, at 15:17, Johan Brichau <johan@inceptive.be> wrote:
I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory.
But yes, I will make a ticket and get some more profiling with that so we can fix it. Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-)
I disagree a bit ;-)
Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up.
This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)).
Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower.
Not by much.
Like Stéphane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines.
I disagree with you there.
Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code.
I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating).
Thierry
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
I can not reproduce this, neither the crash nor the image memory blow up. I tested several ConfigurationOfXXX, with one or more open Browsers.
Can you tell me what Configuration you are trying to load and if this is a fresh pharo image or are there any other packages loaded. And do you have any Nautilus plugins enabled?
regards Nicolai
Same story here. Loading with browsers closed leads to a 10x faster load. Phil Le 27 juin 2014 10:31, "Johan Brichau" <johan@inceptive.be> a écrit :
I reported it as bug 13422 [1].
For now, I was only able to do a comparison before/after which instances
are being kept around.
Johan
[1] https://pharo.fogbugz.com/default.asp?13422#104139
On 26 Jun 2014, at 16:33, Johan Brichau <johan@inceptive.be> wrote:
Nicolai,
It's not a public configuration and it loads quite some packages. I will pick up this issue this evening to get a better reproducible
case.
thx Johan
On 26 Jun 2014, at 16:03, Nicolai Hess <nicolaihess@web.de> wrote:
2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goubier@cea.fr>:
Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit :
On 26 Jun 2014, at 15:17, Johan Brichau <johan@inceptive.be> wrote:
I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a
browser is open because it runs out of memory.
But yes, I will make a ticket and get some more profiling with that so
we can fix it.
Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-)
I disagree a bit ;-)
Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up.
This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)).
Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower.
Not by much.
Like Stéphane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines.
I disagree with you there.
Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code.
I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating).
Thierry
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
I can not reproduce this, neither the crash nor the image memory blow up. I tested several ConfigurationOfXXX, with one or more open Browsers.
Can you tell me what Configuration you are trying to load and if this is a fresh pharo image or are there any other packages loaded. And do you have any Nautilus plugins enabled?
regards Nicolai
Ok then, a simple profile should do it. I'll have a look. I did profile loading Roassal2 with AltBrowser yesterday evening and updates on the browser take 15% of the execution time... Will optimize that. Thierry Le 27/06/2014 11:58, phil@highoctane.be a écrit :
Same story here. Loading with browsers closed leads to a 10x faster load.
Phil
Le 27 juin 2014 10:31, "Johan Brichau" <johan@inceptive.be <mailto:johan@inceptive.be>> a écrit :
I reported it as bug 13422 [1].
For now, I was only able to do a comparison before/after which
instances are being kept around.
Johan
[1] https://pharo.fogbugz.com/default.asp?13422#104139
On 26 Jun 2014, at 16:33, Johan Brichau <johan@inceptive.be
<mailto:johan@inceptive.be>> wrote:
Nicolai,
It's not a public configuration and it loads quite some packages. I will pick up this issue this evening to get a better reproducible
case.
thx Johan
On 26 Jun 2014, at 16:03, Nicolai Hess <nicolaihess@web.de
<mailto:nicolaihess@web.de>> wrote:
2014-06-26 15:37 GMT+02:00 Goubier Thierry <thierry.goubier@cea.fr
<mailto:thierry.goubier@cea.fr>>:
Le 26/06/2014 15:25, Sven Van Caekenberghe a écrit :
On 26 Jun 2014, at 15:17, Johan Brichau <johan@inceptive.be
<mailto:johan@inceptive.be>> wrote:
I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a
browser is open because it runs out of memory.
But yes, I will make a ticket and get some more profiling with
that so we can fix it.
Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-)
I disagree a bit ;-)
Like Thierry said before: we all expect open browsers to react to anything that happens, so when you load a very large amount of code, lots of things change and I can imagine the internal notifications (announcements) overloading the browsers who are struggling to keep up.
This means something can be optimized in the browser... Browsers have a very limited view on the underlying code, more or less a subset of a class methods and their relation in higher stuff, such as the package, which means loading a large body of code has little effect on the Browser (unless it's a live CodeCity instance :)).
Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower.
Not by much.
Like Stéphane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines.
I disagree with you there.
Disabling updates causes problems in many different places (RPackage, for one) and correct implementation of the Browser updates should not slow it down significantly. And it allow us, in the future, to have a responsive GUI while loading code.
I know because after optimising it, it went from very visible to being almost invisible on the profile (far below the time spent #pragma updating).
Thierry
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
I can not reproduce this, neither the crash nor the image memory blow up. I tested several ConfigurationOfXXX, with one or more open Browsers.
Can you tell me what Configuration you are trying to load and if this is a fresh pharo image or are there any other packages loaded. And do you have any Nautilus plugins enabled?
regards Nicolai
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 26 Jun 2014, at 15:25, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Now, there is probably something wrong, and things can probably be tuned, but I think this will always be slower.
As I said, I understand it would be slower. But an image that runs at 100% for a couple of hours and then just dies because it runs out of memory is not my idea of expected behavior. Mind that the memory only gets freed when I close the browser. If I do a marginally smaller load, the load completes but my image size is stuck at 450 MB until I close the open browser. Johan
On 26 Jun 2014, at 15:25, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Like Stéphane said, loading a big batch of code should happen in a special way, disabling updates and firing a full reset at the end - or something along those lines.
If you try that in Pharo3, the RPackage structure is broken. From there on, you cannot do anything reasonable anymore with a package (loading, comparing, publishing,... ) I reported a bug in this sense, but it was flagged as invalid [1] Johan [1] https://pharo.fogbugz.com/default.asp?13213#102915
Le 26/06/2014 15:17, Johan Brichau a écrit :
I will do that, but the main problem is not the loading speed. The real problem is that the image blows up (i.e. crashes) when a browser is open because it runs out of memory.
Try with a simple configuration: the announcements should already be visible on the profile.
But yes, I will make a ticket and get some more profiling with that so we can fix it. Right now, I have to tell my co-workers to close all browsers when they do a full code load interactively... it works but it's a bit ridiculous ;-)
Or switch to another browser :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 25/6/14 19:57, Johan Brichau wrote:
Hi,
It seems that when even a single Nautilus system browser is open and you do a load (using Metacello), there is a huge amount of objects that get created and persisted in the image. This even leads to the point that the image crashes when I try to load our code using a ConfigurationOf. After some time, the Pharo process is stuck at 100%, image size is over 500MB and the entire image becomes unresponsive, finally crashing after an hour or so.
I have not yet found which objects or why, but I just wrestled with this all day to find out what was going on. I first thought that Metacello was in an infinite loop but after noticing that the image was so large (500MB) and that it got reduced to 20% of its size after closing the browser window, I can say that Nautilus is gathering garbage. It is definitely not Metacello because I can trigger the same problem doing a load via Monticello only.
When I load the ConfigurationOf without a single browser open, it loads 5x faster and the image size stays reasonable ouch! we will have to look at that. This is the problem that we do not have a difference between loading code and incrementally compiling code. May be this is the same that happened to me recently when I tried to do ((ConfigurationOfGlamour project version: #development) ignoreImage: true; record), but sadly this is not the same :(
It reminds me a talk of Georg on VW showing that loading code in VW wa spending 95% of the time in refreshing panes. Can you open a bug entry with a high priority?
Is this a known issue? Any thoughts on what may be causing this?
regards! Johan
participants (6)
-
Goubier Thierry -
Johan Brichau -
Nicolai Hess -
phil＠highoctane.be -
stepharo -
Sven Van Caekenberghe