I have a difficult-to-track-down bug that refuses to let itself be reproduced
easily, and yet it occurs every couple of days, with around 10 active clients.
From time to time the client smbd process panics, and from that point on it is
no longer possible to print. Stopping and restarting the smbd service clears the
problem.

The stack trace is as follows:

  BACKTRACE: 14 stack frames:
   #0 smbd(smb_panic+0x11c) [0x81c3aac]
   #1 smbd [0x81b21e2]
   #2 /lib/tls/libc.so.6 [0x420277b8]
   #3 smbd(print_queue_status+0x156) [0x81e13b6]
   #4 smbd [0x808cace]
   #5 smbd(api_reply+0x196) [0x80932f6]
   #6 smbd(reply_trans+0x54b) [0x808a6ab]
   #7 smbd [0x80c8466]
   #8 smbd [0x80c8639]
   #9 smbd(process_smb+0x8f) [0x80c884f]
   #10 smbd(smbd_process+0x167) [0x80c9497]
   #11 smbd(main+0x4bf) [0x822fa9f]
   #12 /lib/tls/libc.so.6(__libc_start_main+0xe4) [0x42015704]
   #13 smbd(ldap_msgfree+0x8d) [0x8076f21]

I had similar problems when using CUPS for printing, both natively and BSD
style. We thought CUPS was the problem, so we pulled that out and installed
lprng to provide printing services.

User authentication is performed with OpenLDAP 2.0.27. The Linux distribution is
Red Hat Linux release 9 (Shrike).

I have placed the client log file (debug level=10) and the smb.conf with the
activity several seconds prior to the segfault at the following location:
http://relay.bpinet.com/david/samba/ .