[856] in Zephyr_Bugs
Re: Zephyr, server bloatage, 2.1.0 vs. 2.0.4...
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Apr 26 23:17:01 1997
To: heath@ofb.net
Cc: ghudson@MIT.EDU, egnor@ofb.net (Dan Egnor), mid@ugcs.caltech.edu,
blakej@ofb.net (Blake A. Jones), bug-zephyr@MIT.EDU
In-Reply-To: Your message of "Sat, 26 Apr 1997 16:53:00 PDT."
<19970426235300.6478.qmail@ofb.net>
Date: Sat, 26 Apr 1997 23:16:39 EDT
From: Greg Hudson <ghudson@MIT.EDU>
The proper place for these queries is bug-zephyr@mit.edu, as
documented in the zephyr README file.
> There was a small obvious leak in subscr.c, line 174, where strings
> weren't freed. This didn't really account for all the lost memory.
> (Patch below.)
You're right, there's a leak there, thanks. (It's a little tricky
because tools like Purify won't catch it, since it's a reference count
leak.) Just as a note, when submitting patches to other people's
code, it would be helpful if you would get the diff arguments in the
correct order (old, then new), use "diff -c" instead of just "diff",
and use the same style as the surrounding code.
> Meanwhile, we could work the server into a state which allocated
> 50MB of RSS, while the heap was only 200k or so. This was a 49MB
> discrepancy. As far as I can tell, it's all a result of heap
> fragmentation.
I assume you mean that the heap was only 200K or so according to your
malloc library (if the SZ of the process is only 200K, then there's a
serious OS problem).
I done very little Zephyr development recently, since I've taken on
other responsibilities. Thus, I don't think I want to make changes as
dramatic as those implied by your patches, but I can see that the
reallocation in uloc.c could be a big lose. So I'll put that down as
something to fix. (If you want to send a patch for just that change,
it might help expedite the matter, but please take into account the
notes above.)
