Hi John,

Check out: http://weeklysqueak.wordpress.com/2006/10/26/image-freezing/ 

What I've seen is that there are problems with switching processes of the
same priority.  The problem I saw was an application that was running on a
separate thread at the idle priority.  Once I bumped the process up by one
the freezing went away.  

I've also see some problems with threading as you mentioned.  The issue
appears to be that thread switching works fine if you have squeak as the
selected application.  Once you click off it, it appears to have some
trouble switching threads.  I wonder if your problem with AVG is not related
to what I saw.  I fixed my problem by managing the treads myself.  I used
the class Monitor and coded my processes by hand.  Monitor is very cool!

You could also try turning on CPUWatcher.  World menu>open>process
browser>start CPUWatcher.  This will suspend processes that are running away
with your app and ask you if you would like to debug at a lower priority.
That gives you the chance to figure out what's going wrong.

Now if you are not doing anything unusual with processes then you can
disregard all these comments.

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists
Ron at USMedRec.com 

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of John Ersatznom
> Sent: Saturday, January 13, 2007 10:22 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Squeak hangs when AVG virus scan is run
> 
> John Ersatznom wrote:
> > As the subject says: Squeak hangs if an AVG anti-virus scan is run. I
> > know, because I have one scheduled for 8 am on Saturdays and exactly at
> > 8 Morphic locked up solid and stopped processing events.
> 
> It's worse. The virus scan completing did not result in Squeak
> recovering. It still keeps flashing "Warning: event buffer overflow" and
> otherwise acting hung. That fresh mouse events aren't finding room to be
> appended to the buffer means that the buffer isn't being emptied from
> the other end, even though the original cause of the problem is gone.
> Apparently it isn't even trying to catch up on the queued-up events and
> begin responding again, and it looks like I'll have to resort once more
> to the three-fingered salute.
> 
> I'm getting rather tired of Squeak crashing at the drop of a hat. My
> Java development tools do not do so. My C/C++ development tools do not
> do so. My other applications do not do so -- not even the ones from
> Microsoft, these days. Those go or wonk out on a weekly basis but not a
> daily one.
> 
> Is there a tweak to make it much more robust, or is it just a matter of
> giving it time to mature more?