(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 operating system. 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. Jeremy.
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 everyone uses. 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 :-). Jeremy.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.