Bug 2682 - smbc_opendir hangs
Summary: smbc_opendir hangs
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: libsmbclient (show other bugs)
Version: 3.0.14a
Hardware: All All
: P3 major
Target Milestone: none
Assignee: Derrell Lipman
QA Contact: Samba QA Contact
Depends on:
Reported: 2005-05-05 13:27 UTC by Maks Verver
Modified: 2005-08-24 10:18 UTC (History)
0 users

See Also:

A packet dump of the communication between the client and the host (output from FreeBSD's tcpdump) (999.74 KB, text/plain)
2005-05-05 13:31 UTC, Maks Verver
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maks Verver 2005-05-05 13:27:11 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 
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.
Comment 1 Maks Verver 2005-05-05 13:31:15 UTC
Created attachment 1205 [details]
A packet dump of the communication between the client and the host (output from FreeBSD's tcpdump)
Comment 2 Jeremy Allison 2005-05-26 13:56:03 UTC
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.
Comment 3 Derrell Lipman 2005-05-27 13:47:48 UTC
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.
Comment 4 Maks Verver 2005-05-28 11:05:36 UTC
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. 
Comment 5 Jeremy Allison 2005-05-28 11:44:05 UTC
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 :-).
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:18:41 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.