Hi
I'm using the 3.9 image, the developer version and I have the UI that freeze sometimes. Usually, when something like that appeared, I used <cmd> . to stop the process but here it's different. Whent the UI freeze, the cpu occupation is around 0% and <cmd> . just doesn't work !
Note, that when the UI is frozen but I can still use seaside applpication and sometimes I can get the hand back after playing with seaside or restarting a session.
Does someone encounter the same problem ?
I use 3.9g-7058 with most of the dev-packages I had this problem with linux (ubuntu), with vm 3.9-7 but also under windows.
Do you think this is a problem is due to my image ?
Thanks
Cédrick
Hi Cedrick,
I've experienced similar problems with a 3.9 image and the 3.9-7 vm (mac and linux). I haven't had them for a while. I never found out why they occured, and they seemed to solve themselves after some time, if you let the image run. It could be a problem that gets solved once some objects get collected or something...
Yann
Quoting Cédrick Béler cbeler@enit.fr:
Hi
I'm using the 3.9 image, the developer version and I have the UI that freeze sometimes. Usually, when something like that appeared, I used <cmd> . to stop the process but here it's different. Whent the UI freeze, the cpu occupation is around 0% and <cmd> . just doesn't work !
Note, that when the UI is frozen but I can still use seaside applpication and sometimes I can get the hand back after playing with seaside or restarting a session.
Does someone encounter the same problem ?
I use 3.9g-7058 with most of the dev-packages I had this problem with linux (ubuntu), with vm 3.9-7 but also under windows.
Do you think this is a problem is due to my image ?
Thanks
Cédrick
it looks like the this issue reported on Mantis: http:// bugs.impara.de/view.php?id=4882
It might be useful to add the datapoints to this report as comments so that they don't get lost.
also, the problem sounds similar to what Bert describes here: http:// lists.squeakfoundation.org/pipermail/squeak-dev/2006-August/107618.html
Adrian
On Sep 22, 2006, at 13:34 , Yann Monclair wrote:
Hi Cedrick,
I've experienced similar problems with a 3.9 image and the 3.9-7 vm (mac and linux). I haven't had them for a while. I never found out why they occured, and they seemed to solve themselves after some time, if you let the image run. It could be a problem that gets solved once some objects get collected or something...
Yann
Quoting Cédrick Béler cbeler@enit.fr:
Hi
I'm using the 3.9 image, the developer version and I have the UI that freeze sometimes. Usually, when something like that appeared, I used <cmd> . to stop the process but here it's different. Whent the UI freeze, the cpu occupation is around 0% and <cmd> . just doesn't work !
Note, that when the UI is frozen but I can still use seaside applpication and sometimes I can get the hand back after playing with seaside or restarting a session.
Does someone encounter the same problem ?
I use 3.9g-7058 with most of the dev-packages I had this problem with linux (ubuntu), with vm 3.9-7 but also under windows.
Do you think this is a problem is due to my image ?
Thanks
Cédrick
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Adrian Lienhard adi@netstyle.ch writes:
it looks like the this issue reported on Mantis: http:// bugs.impara.de/view.php?id=4882
I get something different. Squeak goes into an infinite loop, while this bug reports very low CPU usage.
In my case, Squeak eventually crashes and produces a stack trace involving CompiledMethod>>who and three other methods, infinitely recursing.
This is a 3.9 image and VM 3.9-7. But given the infinite recursion, it looks like an image-level bug.
-Lex
it looks like the this issue reported on Mantis: http:// bugs.impara.de/view.php?id=4882
I get something different. Squeak goes into an infinite loop, while this bug reports very low CPU usage.
In my case, Squeak eventually crashes and produces a stack trace involving CompiledMethod>>who and three other methods, infinitely recursing.
This is a 3.9 image and VM 3.9-7. But given the infinite recursion, it looks like an image-level bug.
for what it worth... in my case, when it happens on windows, I sometimes get a console with a message looping when the mouse is moving over the squeak screen:
WARNING: event buffer overflow
I'm not sure it's related to the same problem, as the console showed up (I think) after I hit <cmd> . several times...
Cédrick
ps: is there a console on the linux/unix vm ? and if yes how to show it
On Mon, Sep 25, 2006 at 02:48:27PM +0200, C?drick B?ler wrote:
ps: is there a console on the linux/unix vm ? and if yes how to show it
No, the "console" is a Windows thing (well not really, the idea goes back a long way, see http://en.wikipedia.org/wiki/Console). Unix systems do not need this. The input, output, and error streams for the Squeak VM can go to the console on Windows, or they are simply connected to whatever shell you are using on a unix system. Actually, the whole idea of the input, output, and error streams are just a part of the commonly accepted C runtime library (available on most operating systems) and are not really part of the Squeak environment at all.
Dave
Hi
To solve, this issue (I often have), I have a workaround inspired by what Bert reported on a similar problem. I load RFB, and then if the UI freezes, I open the VNC controler application (http://localhost:8080/seaside/vnc) .Then supending and resuming the UI process from the seaside interface gives me the hand back in the squeak windows...
not nice, but better than loading changes ;)
Cédrick
Lex Spoon lex@cc.gatech.edu writes:
Adrian Lienhard adi@netstyle.ch writes:
it looks like the this issue reported on Mantis: http:// bugs.impara.de/view.php?id=4882
I get something different. Squeak goes into an infinite loop, while this bug reports very low CPU usage.
In my case, Squeak eventually crashes and produces a stack trace involving CompiledMethod>>who and three other methods, infinitely recursing.
This is a 3.9 image and VM 3.9-7. But given the infinite recursion, it looks like an image-level bug.
After further investigation, my problem came from installing some version of the Refactoring Browser that has its own version of CompiledMethod>>methodClass . Reverting that to the standard Squeak version fixed the problem.
-Lex
squeak-dev@lists.squeakfoundation.org