[GOODIE] [CRASH] [UNIX] Multiuser chat server.

Lex Spoon lex at cc.gatech.edu
Thu Sep 27 05:34:46 UTC 2001



> First, a simple bug to warm everyone up.
>   Invoke squeak with  'squeak -memory'
> *segfault*
> 
> 

Sucky.  Somehow it seems that nobody has ever both typed that line and
reported the results!  Thanks to Ned Konz for a quick fix!



> #1 [crash]:  Try to connect to the server about 10-20 times, don't type in
> anything. It freezes,
> 
> When doing this, I've seen squeak replace transcript windows with big red
> squares (with a yellow cross through the middle of them. Though it brings
> up a debugger before completely drawing it.  At that point, squeak seems
> to no longer see the mouse or keyboard. Though it will refresh the screen.
> Not even emergency-escape works.

Are you printing to Transcript from a background thread?  I'm not sure
that's safe (it definitely wasn't safe, in an older version of Squeak,
but maybe it got fixed.)

If that's not it, then watch out in general for background threads doing
UI stuff.

By the way, in Morphic, do you know about #step?  My favorite way to set
up a server in Squeak (which, by the way, really irritates some of the
purists on the list!), is to poll the socket from a #step method.  For a
chat server, 100 updates a second is often fast enough.


> #2 [crash]: Connect to the server with one or more times. Paste a lotta
> text into the windows... hundreds of kilobytes. Try more windows and more
> concurrent connections.. I've seen walkbacks, strange crashes, and
> complete.

Same thing, most likely.

Although, it might be a memory problem.  Dealing with out-of-memory is
very hard in Squeak, and in fact squeak doesn't deal very well with it. 
:|



> 
> #3 [crash]: There was a diff patch a few weeks ago that fixes this, but
> the socket finalization C code is in error, and may crash, both when
> saving an image with open sockets, or when loading an image that had open
> sockets on it when it was saved. I've not checked for a more recent unix
> sourcetree to confirm this. It may help to reduce the deadlineSecs:
> MuckSocket>>waitForData to one second. (See #5 for more on this)

Yep, I'm pretty sure this is in the patches from my patches page.  If
you are doing a lot of networking, you probably want to use my version
instead of Ian's -- a big chunk of the bugfixes on there come from
things found due to running Swiki servers.


> 
> #5 [annoyance]: The sockets code appears to be somewhat flawed when
> waiting for data. Connect to the echo server, and wait 20 seconds and type
> a line. It comes out immediately. Type another line a second later, and
> squeak waits about 10 seconds. Its like after a successful read, it will
> not do another read on the socket for deadlineSecs
> (MuckSocket>>waitForData) But, if its been more than 10 seconds since a
> read, it will notice the new data immediately.

This is odd.  It might be a real bug.  I don't have time to chase it
myself.  :(  I'd be more tempted, though, if you can make a very simple
replication of it.

It might not be a bug, though -- you mentioned that there is some busy
looping somewhere?  If one thread is busy-looping, other threads of an
equal or lower priority will not get access.  Thus, maybe some critical
thread of yours is simply not getting access.



> #6 [flaw] There appear to be several busywaits in squeak. Try
> connecting to the server, but doing nothing. You may find squeak consuming
> all CPU. My code responsible for network reading is::
> 
>    MuckPlayerConnection>>networkReaderLoop,
>    MuckSocket>>networkGetSingleLine
>    MuckSocket>>waitForData

By the way, waitForData also returns if the socket has died; doo you
handle that case?

I run Squeak all the time and don't see 100% CPU get used.  So, it's not
a given....


> I have a 10 second timeout, but I believe the underlying C code is
> not waiting even despite this.

It's entirely possible -- this even sounds familiar.




More information about the Squeak-dev mailing list