The Samba-Bugzilla – Bug 2682
Last modified: 2005-08-24 10:18:41 UTC
(The application version should actually be 3.0.14.)
When opening a specific share on a specific server on my LAN, libsmbclient
hangs in a call to smbc_opendir, burning CPU cycles and allocating more and
more memory until it exhausts the available memory and is killed by the
This bug always occurs (so it is reproducable) when using the libsmbclient
library (both in my own code and when using the smbclient command line
utillity). I tested it on an x86 box running FreeBSD 5.3, and an x86-64 box
running Gentoo Linux (so it is probably not related to operating system
specific facilities or compiler specific optimizations, although in both cases
GCC 3.4 was used).
The host that contains this 'broken' share is a Windows 2000 server. I will
attach a network trace (only the beginning'; it goes on and on until the
process is killed). Please let me know if this is a known problem, or if you
need any more information to figure out what is going on.
Created attachment 1205 [details]
A packet dump of the communication between the client and the host (output from FreeBSD's tcpdump)
This is not a useful packet dump. Packet dumps are not TEXT messages, they are
binary snapshots of the real traffic on the network. We can't analyse this bug
with this data.
This bug is likely fixed by svn checkin r6993. If the W2k share is FAT, there
was a bug that caused reading large directories to loop forever consuming memory.
If the bug still occurs after upgrading beyond r6993, please reopen this bug and
provide a tcpdump or ethereal capture in BINARY format that shows the problem,
and we'll work it from there.
Derrell: I checked out the latest revision (7057) and the bug is indeed gone.
Jeremy: I can assure you that the network traffic described in human-readable
file is actually very real. I would be happy to provide a binary packet dump,
but it would have been nice if you would have asked for it in a more
constructive and less demeaning tone. The prefered file format was not obvious
to me, for as far as I know there exists no universal binary file format that
In any case, the bug is resolved; thanks for the help! I'm anticipating the
next official release that includes this fix.
I'm sorry, this is a pet peeve of mine. People keep sending in text attachments
of network traffic and expect us to do something with them. As it takes a while
to get someone to do this usually, obviously their expectations are high when
they send it to us. It's very frustrating to eagerly await a network trace and
then find text files instead, but I apologise for taking it out on you. I'm
hoping to train people to send raw network dumps instead :-).
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.