In a setup with samba, windows XP and a printer configured with drivers on the print$ share (point'n'print) it sometimes happens that the memory consumption of an smbd process increases without limit.
There seems to be a bug in some versions of the windows XP spooler that causes it to go into a loop in which it repeatedly and frequently issues the rpc calls SPOOLSS_OPENPRINTEREX, SPOOLSS_ENUMJOBS, SPOOLSS_GETPRINTERDATA and SPOOLSS_CLOSEPRINTER (not necessarily in this order).
A printout of the memory usage of such a process, acquired with smbcontrol <pid> pool-usage, shows that most of this memory is tied up in references to NT_PRINTER_INFO_LEVEL. In this specific case the number of references increases with about 230 per minute, causing the virtual memory usage to increase by about 4 MiB per minute.
As an example:
root@server:~# ps axfuw | grep 3100
user 3100 0.9 24.7 695188 255404 ? S 17:04 0:18 \_ /usr/sbin/smbd -D
smbcontrol 3100 pool-usage | grep -cw NT_PRINTER_INFO_LEVEL 7605
And some additional information:
running on slackware 10.1, kernel 2.4.32, glibc 2.3.4, cups 1.1.23
CFLAGS="-O2 -march=i486 -mcpu=i686" ./configure \
Can you add either a debug level 10 or an ethereal trace of smbd when the client is doing this ? I'm hoping to track down where we're leaking the NT_PRINTER_INFO_LEVEL structs.
Created attachment 2062 [details]
There were some error paths where the NT_PRINTER_INFO_LEVEL wasn't being freed. Please try this patch.
Created attachment 2063 [details]
Here's an additional one that stops a double-free in the info level 2 case.
Now we do the frees in the same place.
Created attachment 2065 [details]
Level 3 and 10 log of the smbd process
This is a log file with logs from the process that is logging the memory. It starts with log level 3 and changes to log level 10 after some time.
I am testing samba 3.0.23a with both patches, and so far I can see no memory increase (nor references to NT_PRINTER_INFO_LEVEL structs in a pool-usage output) while a level 3 log still shows the continous access to the printer.
It seems the patches solve the problem.
Fixed for 3.0.23b.