Bug 1281 - Samba-3.0.1 Critical Memeory leak on s390 arch modifying print driver properties via Windows APW
Samba-3.0.1 Critical Memeory leak on s390 arch modifying print driver propert...
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Printing
3.0.1
All Linux
: P2 major
: none
Assigned To: Gerald (Jerry) Carter
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-22 05:35 UTC by GrantB
Modified: 2005-08-24 10:18 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description GrantB 2004-04-22 05:35:10 UTC
Testing upgrade of Print Servers from Samba-2.2.8a to Samba-3.0.1 on SuSE SLES8
(s390 Arch). Samba is joined as a member of an NT4 domain (so using winbindd)
and configured to offer up W2K print drivers via the print$ share, with
approximately 130 printers and 35 different print drivers defined.

When attempting to change printer properties via the Windows Printer Properties
(I'm using a Win XP Client) the associated smbd process appears to loop (using
lots of CPU) and leak memory. Depending on the speed of your environment and how
much virt memory available this can exhaust the available memory in a few minutes.

Since seeing this on a client machine I've been able to reproduce using a
similar Linux configuration running under the Hercules s390 emulator on my
Athlon machine. Unfortunately, for some reason I've not been able to replicate
the same problem under i386. I know s390 playpens can be hard to come by so am
happy to provide access to what I've already got here running under Herc. It's
not a great place to compile stuff due to the emulation overhead. Even with
distcc and ccache installed it's still real slow.

At this point the only real diagnostic data I've obtained has been from log.smbd
at debuglevel 3 and a tcpdump sniff. While the thing loops and the storage grows
the following is repeated within the log:
[2004/04/22 09:54:16, 3] smbd/process.c:process_smb(890)
  Transaction 17561 of length 168
[2004/04/22 09:54:16, 3] smbd/process.c:switch_message(685)
  switch message SMBtrans (pid 5525)
[2004/04/22 09:54:16, 3] smbd/ipc.c:reply_trans(538)
  trans <\PIPE\> data=80 params=0 setup=2
[2004/04/22 09:54:16, 3] smbd/ipc.c:named_pipe(334)
  named pipe command on <> name
[2004/04/22 09:54:16, 3] smbd/ipc.c:api_fd_reply(296)
  Got API command 0x26 on pipe "spoolss" (pnum 71d5)free_pipe_context:
destroying talloc pool of size 0
[2004/04/22 09:54:16, 3] rpc_server/srv_pipe.c:api_rpcTNP(1509)
  api_rpcTNP: rpc command: SPOOLSS_GETPRINTERDATA
[2004/04/22 09:54:16, 3] rpc_server/srv_pipe_hnd.c:free_pipe_context(544)
  free_pipe_context: destroying talloc pool of size 22
[2004/04/22 09:54:16, 3] smbd/process.c:process_smb(890)
  Transaction 17562 of length 168
[2004/04/22 09:54:16, 3] smbd/process.c:switch_message(685)
  switch message SMBtrans (pid 5525)
[2004/04/22 09:54:16, 3] smbd/ipc.c:reply_trans(538)
  trans <\PIPE\> data=80 params=0 setup=2
[2004/04/22 09:54:16, 3] smbd/ipc.c:named_pipe(334)
  named pipe command on <> name
[2004/04/22 09:54:16, 3] smbd/ipc.c:api_fd_reply(296)
  Got API command 0x26 on pipe "spoolss" (pnum 71d6)free_pipe_context:
destroying talloc pool of size 0
[2004/04/22 09:54:16, 3] rpc_server/srv_pipe.c:api_rpcTNP(1509)
  api_rpcTNP: rpc command: SPOOLSS_GETPRINTERDATA
[2004/04/22 09:54:16, 3] rpc_server/srv_pipe_hnd.c:free_pipe_context(544)
  free_pipe_context: destroying talloc pool of size 22

From my sniff of packets i get a tonne of the following:
45   0.872772 192.168.200.3 -> 10.250.0.217 TCP netbios-ssn > 1388 [ACK]
Seq=2080 Ack=3360 Win=9681 Len=0
 46   0.903968 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11993
ctx_id: 0
 47   0.906787 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12001
opnum: 26 ctx_id: 0
 48   0.938085 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11994
ctx_id: 0
 49   0.938988 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12002
opnum: 26 ctx_id: 0
 50   0.940409 192.168.200.3 -> 10.250.0.217 TCP netbios-ssn > 1388 [ACK]
Seq=2288 Ack=3696 Win=9681 Len=0
 51   0.960093 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11995
ctx_id: 0
 52   0.960824 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12003
opnum: 26 ctx_id: 0
 53   0.980585 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11996
ctx_id: 0
 54   0.981668 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12004
opnum: 26 ctx_id: 0
 55   1.003580 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11997
ctx_id: 0
 56   1.004887 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12005
opnum: 26 ctx_id: 0
 57   1.023244 192.168.200.3 -> 10.250.0.217 DCERPC Response: call_id: 11998
ctx_id: 0
 58   1.024355 10.250.0.217 -> 192.168.200.3 DCERPC Request: call_id: 12006
opnum: 26 ctx_id: 0
 59   1.059648 192.168.200.3 -> 10.250.0.217 TCP netbios-ssn > 1388 [ACK]
Seq=2704 Ack=4368 Win=9681 Len=0

To re-create on s390 here's some additional info you're probably going to need:
Distrib: SuSE SLES8: Kernel 2.4.21-102-default
glibc: glibc-2.2.5-115
lprng: lprng-3.8.12-50 (havn't tried CUPS in this envr)

Samba: * Have used the RPMS from
ftp://ftp.suse.com/pub/people/gd/samba3/sles8-s390/samba3-3.0.1, however have
seen similar problems when built from stable source tree.
sles81:/etc # rpm -qa |grep -i samba
samba3-3.0.1-0
samba3-client-3.0.1-0
samba3-doc-3.0.1-0
samba3-winbind-3.0.1-0

I can fairly consistently re-create the stg leak from Win XP by performing the
following. However the problem doesn't always occur at the same point each time.
Sometime it doesn't actually occur every time, but more often that not if I
follow this sequence it will occur at some point:
In XP do a Start -> Run -> \\sles81
Double click on Q941 to install and load driver (printcap entry detailed below)
Once installed select properties of Q941 from local XP printers folder and
change say the orientation in the 'Printing Preferences'.

Q941 is defined in printcap on my test envr as follows:
# Lexmark Optra S 1250 - Q941
Q941
        :lp=/dev/null
        :rp=PASS
        :sd=/var/spool/lpd/%P

As u can see by the comment it has the Lexmark S 1250 driver assigned.

I suspect this may be more reproducible with the large number of
drivers/printers we have defined. If needed I could forward all of the tdb files
and the contents of the printers dir.

A tdbbackup -v reveals no tdb problems.

/etc/samba/smb.conf
# Global parameters
[global]
        workgroup = DBR05A
        netbios name = SLES81
        server string = Samba Printserver for Testing
        os level = 65
        domain master = no
        domain logons = no
        preferred master = auto
        local master = yes
        wins server = 10.250.0.150
        security = DOMAIN
        encrypt passwords = yes
        password server = gollum
        max log size = 10000
        log level = 3
        syslog = no
        socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=8192 SO_SNDBUF=8192
        max xmit = 65536
        dns proxy = No
        map to guest = never
        guest account = nobody
        winbind uid = 10000-20000
        winbind gid = 10000-20000
        winbind separator = +
        printing = lprng
        printer admin = @DBR05A+"Print Admin Priv S3",@DBR05A+"Domain
Admins",DBR05A+grantb
                                                                                
#
# Start of the default options for defined shares
#
        browseable = yes
        read only = no
        guest ok = no
#       posix locking = no
        create mask = 0770
        dns proxy = No
        map to guest = never
        guest account = nobody
        winbind uid = 10000-20000
        winbind gid = 10000-20000
        winbind separator = +
        printing = lprng
        printer admin = @DBR05A+"Print Admin Priv S3",@DBR05A+"Domain
Admins",DBR05A+grantb
                                                                                
#
# Start of the default options for defined shares
#
        browseable = yes
        read only = no
        guest ok = no
#       posix locking = no
        create mask = 0770
        directory mask = 0770
 
[homes]
        path = /home/smbshare/%U
        comment = Home Directory for %U on %L
        browseable = no
 
[print$]
        path = /etc/samba/printers
        guest ok = no
        read only = yes
        write list = @DBR05A+"Print Admin Priv S3",@DBR05A+"Domain
Admins",DBR05A+grantb
        admin users = @DBR05A+"Print Admin Priv S3",@DBR05A+"Domain
Admins",DBR05A+grantb
        create mask = 0664
        directory mask = 0775
        force group = +root
        posix locking = no
 
[printers]
        path = /var/spool/samba
        printable = yes
        browseable = yes
        guest ok = no
        printing = lprng
#       use client driver = yes
#       default devmode = yes
        print command =      /usr/bin/lpr  -U%U@%M -P%p -r %s
        lpq command   =      /usr/bin/lpq  -U%U@%M -P%p
        lprm command  =      /usr/bin/lprm -U%U@%M -P%p %j
        lppause command =    /usr/sbin/lpc -U%U@%M hold %p %j
        lpresume command =   /usr/sbin/lpc -U%U@%M release %p %j
        queuepause command = /usr/sbin/lpc -U%U@%M -P%p stop
        queueresume command = /usr/sbin/lpc -U%U@%M -P%p start

Sorry about the size of this :-)

Cheers, GrantB
Comment 1 Gerald (Jerry) Carter 2004-08-27 10:14:15 UTC
I fixed a few memory leaks related to the print handle cache.
Don't remember what vcersion though.  Please reopn this bug 
if the leak still exists in the latest 3.0.x release.
Comment 2 Gerald (Jerry) Carter 2005-08-24 10:18:03 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.