[Pharo-project] Process stuck in 10156+OB?
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time. - problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting. It's a weird behaviour. -- Simon
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-) I will put it back in. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-)
may be not but in Squeak you never know :) This is why we should clean clean refactor..... :) Stef PS: marcus you are improving you did not bash yourself this time :)
2008/11/18 Marcus Denker <denker@iam.unibe.ch>:
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-) I will put it back in.
Don't be so haste :) I'd rather try to reproduce the problem and find solution. a 100% cpu hog at startup time could be a problem with Delays, or different semaphores which has dropped during #clearExternalObjects but not correctly reinstantiated again at following startup phase.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Let us know Igor, this triggered my curiosity. Alexandre On 18 Nov 2008, at 14:25, Igor Stasenko wrote:
2008/11/18 Marcus Denker <denker@iam.unibe.ch>:
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-) I will put it back in.
Don't be so haste :) I'd rather try to reproduce the problem and find solution.
a 100% cpu hog at startup time could be a problem with Delays, or different semaphores which has dropped during #clearExternalObjects but not correctly reinstantiated again at following startup phase.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 18 nov. 08, at 18:32, Alexandre Bergel wrote:
Let us know Igor, this triggered my curiosity.
Alexandre
On 18 Nov 2008, at 14:25, Igor Stasenko wrote:
2008/11/18 Marcus Denker <denker@iam.unibe.ch>:
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-) I will put it back in.
Don't be so haste :) I'd rather try to reproduce the problem and find solution.
Should be easy to reproduce :) but I can send my image to whoever is able to work on it.
a 100% cpu hog at startup time could be a problem with Delays, or different semaphores which has dropped during #clearExternalObjects but not correctly reinstantiated again at following startup phase.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
2008/11/18 Simon Denier <Simon.Denier@inria.fr>:
On 18 nov. 08, at 18:32, Alexandre Bergel wrote:
Let us know Igor, this triggered my curiosity.
Alexandre
On 18 Nov 2008, at 14:25, Igor Stasenko wrote:
2008/11/18 Marcus Denker <denker@iam.unibe.ch>:
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-) I will put it back in.
Don't be so haste :) I'd rather try to reproduce the problem and find solution.
Should be easy to reproduce :) but I can send my image to whoever is able to work on it.
send it to me, i'll try to figure out what is wrong
a 100% cpu hog at startup time could be a problem with Delays, or different semaphores which has dropped during #clearExternalObjects but not correctly reinstantiated again at following startup phase.
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
I can confirm that. I got the exactly same behavior when updating from 10024 to 10157. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On 18.11.2008, at 18:25, Igor Stasenko wrote:
2008/11/18 Marcus Denker <denker@iam.unibe.ch>:
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-) I will put it back in.
Don't be so haste :)
:-) I nevertheless did a 10158 which has the Process again in the special objects array. (This way people get a warning if they want to change the layout of the class).
I'd rather try to reproduce the problem and find solution.
good!
a 100% cpu hog at startup time could be a problem with Delays, or different semaphores which has dropped during #clearExternalObjects but not correctly reinstantiated again at following startup phase.
I thin this one is *not* related (negative results are results, too ;-)) Issue 232: Recreate Special Objects Array should preserve external semaphores + Fix Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
If some people want to give it a try with a Mac VM, here is the image: http://dl.free.fr/ttFRq8FQM On 18 nov. 08, at 22:02, Marcus Denker wrote:
On 18.11.2008, at 18:25, Igor Stasenko wrote:
2008/11/18 Marcus Denker <denker@iam.unibe.ch>:
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-) I will put it back in.
Don't be so haste :)
:-)
I nevertheless did a 10158 which has the Process again in the special objects array. (This way people get a warning if they want to change the layout of the class).
I'd rather try to reproduce the problem and find solution.
good!
a 100% cpu hog at startup time could be a problem with Delays, or different semaphores which has dropped during #clearExternalObjects but not correctly reinstantiated again at following startup phase.
I thin this one is *not* related (negative results are results, too ;-))
Issue 232: Recreate Special Objects Array should preserve external semaphores + Fix
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
On 18 nov. 08, at 22:02, Marcus Denker wrote:
On 18.11.2008, at 18:25, Igor Stasenko wrote:
2008/11/18 Marcus Denker <denker@iam.unibe.ch>:
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB, save it as new image, quit and then relaunch the new image, my new image is unusable because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157 - however there seems to be no problem if I just continue to work in the image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing Process from the specialObjectsArray was a dunb idea ;-) I will put it back in.
Don't be so haste :)
:-)
I nevertheless did a 10158 which has the Process again in the special objects array. (This way people get a warning if they want to change the layout of the class).
I still got this behavior after updating to 10159. Perhaps this is not related to special objects after all. Then this is more related to OB, since it only happens with images where loadOB has been performed.
I'd rather try to reproduce the problem and find solution.
good!
a 100% cpu hog at startup time could be a problem with Delays, or different semaphores which has dropped during #clearExternalObjects but not correctly reinstantiated again at following startup phase.
I thin this one is *not* related (negative results are results, too ;-))
Issue 232: Recreate Special Objects Array should preserve external semaphores + Fix
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
participants (6)
-
Alexandre Bergel -
Igor Stasenko -
Lukas Renggli -
Marcus Denker -
Simon Denier -
Stéphane Ducasse