Time-critical problem at Sun: exploding smbd memory usage --- Here's the real fix!

[Richard Bollinger]

Using an old memory allocation debugging / tracking tool (mem_man), I monitored what was going
on while smbd processed our 300+ printer printcap file...

After processing 300 printers, the stats were as follows:
Mem Manager : 196110 blocks, allocation 11553K, real allocation 11553K, 0 errors

Of that, talloc() accounted for 192036 of the malloc() calls and 11280K of the space allocated.

Sure, all of that would be freed eventually, but it amounts to a torture test for the system's
malloc() / free() capabilities, which apparently aren't as aggressive at recovering / releasing
free space with Solaris as with Linux :-).

I tracked the problem to an O(N^2) loop... add_all_printers() calls pcap_printer_fn(), which in
turn calls lp_add_one_printer(), which in turn calls lp_servicenumber(), which in turn calls
lp_servicename(), which in turn calls lp_string(), which in turn calls talloc().

Here's the fix to lp_servicenumber(), based on similar code in getservicebyname()...

--- ../source/param/loadparm.c Fri Aug 31 07:15:36 2001
+++ ./param/loadparm.c Wed Sep  5 22:11:36 2001
@@ -3418,7 +3424,8 @@

  for (iService = iNumServices - 1; iService >= 0; iService--)
  if (VALID(iService) &&
-     strequal(lp_servicename(iService), pszServiceName))
+     ServicePtrs[iService]->szService &&
+     strequal(ServicePtrs[iService]->szService, pszServiceName))
  break;

  if (iService < 0)

After the fix is in, the same memory monitoring tools reveal these stats:
Mem Manager : 4054 blocks, allocation 537K, real allocation 537K, 0 errors

Of that, talloc() now accounts for only 7 of the malloc() calls and 357 bytes allocated.

Rich Bollinger, Elliott Company
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixleaks.patch
Type: application/octet-stream
Size: 419 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20010905/dc3d763d/fixleaks.obj