Severe memory leak problem

[Brian Bisaillon]

I'm pretty new to Erlang and I'm writing a multi-threaded chat server. I have
this problem where if I make a client program continuously send data to my
server, the beam process that runs the servers keeps increasing in memory
(reported by top). If I leave it on long enough my system becomes very unstable
and even crashes. I've traced the memory leak to an area of my code. I don't
understand why it is happening though. The code works and to me everything
looks fine. It even looks like all the variables are reinitialized in my
program with every tail recursive call. I don't understand why it keeps sucking
up more memory. I have attached the client & server source code to this email.
Can someone please help me out on this? If you run the debugger, set a
breakpoint somewhere in the receive_packet function and step through it. At the
same time look at the memory being used by the beam process. You'll notice
that as you step through it, the memory will keep increasing. I even tried the
new R7A version of Erlang and it still didn't fix the problem. It's a serious
problem because if I had say 100 clients sending data simultaneously, my server
would run out of memory. Compared to something like Apache or other servers
that can handle many clients and use little memory, it's not a good thing.
Maybe it's a design flaw in my program? Suggestions needed :-)

Thanks a lot! It's important to me because it's part of a project I'm doing for
college. I decided to do it because I had already coded a big part of my chat
server so why not :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtclient.erl
Type: text/english
Size: 742 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20000922/3d597e23/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtserver.erl
Type: text/english
Size: 7224 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20000922/3d597e23/attachment-0001.bin>