Quantcast

WinXP/x64 - MFC CFile objects leak parent directory handles

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

WinXP/x64 - MFC CFile objects leak parent directory handles

Dragan Krnic-2
Samba 3.0.28-0.1.95-1624-SUSE-SL10.3

A strange problem (best read in a proportional font).

It only happens on an x64 XP client when accessing
a Samba share. The exact same program runs fine
on the same x64 XP client when the share accessed
is on a Windows server or when it is run on a 32-bit
XP client, regardless of whether the share belongs to
a Samba server or to a Windows server.

I have traced the problem to a local instantiation of an
object of MFC class CFile in the line 170 of the following
code:

166 CString CWaitForChangedFile::GetFileContent()
167 {       if (mstrFilePath.IsEmpty())
168                 return "";
169         _my_TRY
170                 CFile file(mstrFilePath,
                                    CFile::modeRead |
                                    CFile::shareDenyNone);
171                 int size = (int)file.GetLength();
172                 CString text;
173                 file.Close();
174                 text.Format("%d", size);
175                 return text;
176         _my_REPORT_EXCEPTION_ALL
177                 return "ERROR!!!!!";
178 }

When the programm using this method is run on a
Windows XP Professional x64 Edition and a file
"mstrFilePath" is opened for read with an oplock
of type "DenyNone" on a Samba share, as above
in line 170, a new handle to the parent directory
remains stuck until the program is stopped, which
should actually be removed when the program exits
the method. The handle looks something like this
in the output of "handle.exe -a -p thisProg.exe":

  46C: File (RWD) \Device\LanmanRedirector\;X:0000000000014c30\samba\T01\

On the Linux side (SuSE 10.3, kernel 2.6.22.13-0.3-default)
I can trace this behaviour to the fact that the transactions in
the lines 39 through 60 in the following formatted audit log
don't appear when the programm is run on an x64 XP, which
DO get executed when the program is run on a 32-bit XP
(the lines following the "getxattr" of "user.DOSATTRIB"
after setting the "kernel_flock" on the already opened file).

 1                 stat         T01/T01.ini
 2             getxattr         T01/T01.ini:user.DOSATTRIB
 3 THE PREVIOUS 2 LINES REPEATED 14 TIMES
 4                 stat         .
 5                 stat         T01
 6             getxattr No data T01|user.DOSATTRIB
 7                 stat         T01/T01.ini
 8              opendir         T01
 9                 stat         T01/T01.ini
10                 stat         T01/T01.ini
11     sys_acl_get_file         T01/T01.ini
12             getxattr No data T01/T01.ini:user.SAMBA_PAI
13    sys_acl_get_entry
14 sys_acl_get_tag_type
15  sys_acl_get_permset
16     sys_acl_get_perm
17     sys_acl_get_perm
18    sys_acl_get_entry
19 sys_acl_get_tag_type
20  sys_acl_get_permset
21     sys_acl_get_perm
22     sys_acl_get_perm
23    sys_acl_get_entry
24 sys_acl_get_tag_type
25  sys_acl_get_permset
26     sys_acl_get_perm
27     sys_acl_get_perm
28    sys_acl_get_entry
29     sys_acl_free_acl
30          fget_nt_acl         T01/T01.ini
31             getxattr         T01/T01.ini:user.DOSATTRIB
32             closedir
33                 stat         T01/T01.ini
34                 stat         T01
35             getxattr         T01/T01.ini:user.DOSATTRIB
36                 open       r T01/T01.ini
37         kernel_flock         T01/T01.ini
38             getxattr         T01/T01.ini:user.DOSATTRIB
39 *************** stat         T01/T01.ini
40     sys_acl_get_file         T01/T01.ini
41             getxattr No data T01/T01.ini:user.SAMBA_PAI
42    sys_acl_get_entry
43 sys_acl_get_tag_type
44  sys_acl_get_permset
45     sys_acl_get_perm
46     sys_acl_get_perm
47    sys_acl_get_entry
48 sys_acl_get_tag_type
49  sys_acl_get_permset
50     sys_acl_get_perm
51     sys_acl_get_perm
52    sys_acl_get_entry
53 sys_acl_get_tag_type
54  sys_acl_get_permset
55     sys_acl_get_perm
56     sys_acl_get_perm
57    sys_acl_get_entry
58     sys_acl_free_acl
59           get_nt_acl         T01/T01.ini
60 ************** fstat         T01/T01.ini
61             getxattr         T01/T01.ini:user.DOSATTRIB
62                fstat         T01/T01.ini
63             sendfile         T01/T01.ini

I guess that Samba sends the same information in response
to a "getxattr" no matter what the bitness of the client is.
So it's probably the client SMB code on x64 XP which is
doing something in a different way when it finds out that the
share belongs to a Samba server.

 No combination of oplock settings makes any difference.

Does anyone know how to avoid this problem?
Should I provide some more diagnostics?
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Volker Lendecke
On Mon, Feb 04, 2008 at 07:07:36PM +0100, Dragan Krnic wrote:
> Does anyone know how to avoid this problem?
> Should I provide some more diagnostics?

Your smb.conf, debug level 10 logs and sniffs of all
combinations please!

Volker

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Dragan Krnic-2
On 2/4/08, Volker Lendecke <[hidden email]> wrote:
>
> On Mon, Feb 04, 2008 at 07:07:36PM +0100, Dragan Krnic wrote:
> > Does anyone know how to avoid this problem?
> > Should I provide some more diagnostics?
>
> Your smb.conf, debug level 10 logs and sniffs of all
> combinations please!
>
> Volker

my effective smb.conf:

  1
  2 [global]
  3         workgroup = PMN1
  4         netbios name = PMN93
  5         server string = ""
  6         wins server = 172.24.204.184
  7         preferred master = no
  8         local master = no
  9         domain master = no
 10         server signing = no
 11         encrypt passwords = yes
 12         security = domain
 13         time server = no
 14         passwd program = /usr/bin/passwd %u
 15         username level = 3
 16         unix password sync = yes
 17         lanman auth = no
 18         dos filemode = yes
 19         log level = 1
 20         debug timestamp = yes
 21         log file = /var/log/samba/%m
 22         max log size = 65536
 23         socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
 24         max xmit = 65535
 25         unix charset = UTF8
 26         display charset = UTF8
 27         os level = 31
 28         lock dir = /var/lock/samba/locks
 29         pid directory = /var/lock/samba
 30         create mask = 0664
 31         directory mask = 0775
 32         hide dot files = no
 33         map system = no
 34         map hidden = no
 35         map archive = no
 36         store dos attributes = yes
 37         map acl inherit = yes
 38         host msdfs = no
 39         printing = cups
 40         printcap name = cups
 41
 42 [homes]
 43         comment = Home Directories
 44         valid users = %U
 45         read only = no
 46         inherit permissions = yes
 47         security mask = 0777
 48         directory security mask = 0777
 49         browseable = no
 50         store dos attributes = yes
 51
 52 [PRIMA]
 53         comment = "for Project work"
 54         directory security mask = 0777
 55         dos filetimes = yes
 56         inherit permissions = yes
 57         map system = no
 58         oplocks = no
 59         path = /local/PRIMA
 60         read only = no
 61         security mask = 0777
 62         hide unreadable = yes
 63         map hidden = no
 64         map archive = no
 65         store dos attributes = yes
 66         map acl inherit = yes
 67         use sendfile = yes
 68         strict sync = yes
I have enclosed 4 files compressed with bzip2 documenting the
problem when an x64 client opens a file in a Samba share:

1. messages.x64.fmt.bz2   formatted full_audit log
2. pmn33.x64.bz2             formatted level 10 samba log
3. wireshark.out.bz2         formatted wireShark print-out
4. x64-26-07.bz2             capture file with relevant 200 packets

All files include data captured at 16:26:07 today.
The transaction opening the file for read, setting
kernel_flock and returning xattr should start at about
packet 69 in capture file.

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Volker Lendecke
On Tue, Feb 05, 2008 at 06:25:03PM +0100, Dragan Krnic wrote:
> 1. messages.x64.fmt.bz2   formatted full_audit log
> 2. pmn33.x64.bz2             formatted level 10 samba log
> 3. wireshark.out.bz2         formatted wireShark print-out
> 4. x64-26-07.bz2             capture file with relevant 200 packets

This is not usable, sorry. Remove the formatting and send
sniffs *COMPARING* both behaviours.

Volker

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Dragan Krnic-2
On 2/5/08, Volker Lendecke <[hidden email]> wrote:
> On Tue, Feb 05, 2008 at 06:25:03PM +0100, Dragan Krnic wrote:
> > 1. messages.x64.fmt.bz2   formatted full_audit log
> > 2. pmn33.x64.bz2             formatted level 10 samba log
> > 3. wireshark.out.bz2         formatted wireShark print-out
> > 4. x64-26-07.bz2             capture file with relevant 200 packets
>
> This is not usable, sorry. Remove the formatting and send
> sniffs *COMPARING* both behaviours.

Sorry, Volker, I didn't manage to get both behaviours in one session
but here we go for the behaviour of a Windows XP/ia32:

The sequence of

    opening the file for read,
    getting the oplock (kernel_flock)
    getxattr

in lines 274 through 276 of the formatted full_audit log in the said file
# 1 messages.x86.fmt.bz2 flips directly to "fstat". But in the new file
# 1 messages.ia32.fmt.bz2 you can see that there is a whole lot more
being done on a 32-bit Windows XP, before it eventually continues
with "fstat" etc. The transactions in lines 278 ("stat") through 298
("get_nt_acl")
are missing in the full_audit log when the client is a Windows XP/x64
and this practically means that the handle on the parent's directory
never gets released by the client.

Since all of the transactions in these files are taking place at exactly the
same time today at 20:38:19, just as all the transactions occurred exactly
same time yesterday at 16:26:07, I've removed the timestamp, host name,
service name, user name and client's IP-address to make the file more
compact and easier to read. The format gives 20 characters (the length
of "sys_acl_get_tag_type") to the action, 6 char for sucess (empty) or
failure (NoDATA or NoFILE) and the rest of the line is the path name
relative to the share's root, followed eventually by a stream name (e.g.
user.DOSATTRIB) .

I've abstained from formatting the samba log at level 10 in the new file:
#2 pmn30.ia32.bz2. I'm sorry, that the previous file was formatted in a
way that _I_ find easiest to follow - by coalescing all the lines between two
timestamps into one line. I'm a bit attention-challenged and can't see
the wood when there are too many trees around:-), so I thought everyone
will like the way I look at it. Anyway the new file contains 12322 lines
just as they are spewed out by Samba. I can't see where the kernel_flock
is logged in Samba level 10 - I guess around line #11675 or so but you'll
find it I'm sure.

The 3rd file in this letter is the raw capture file "ia32-20-38-19.bz2" with
186 relevant packets at that point in time. The problem transaction begins
at packet #69. I haven't enclosed the wireShark print-out of all expanded
packets at all, which you can produce yourself if you need it.

I hope you'll see what's wrong when an x64 XP client is communicating
with a Samba server as opposed to when a 32-bit XP client is doing it,
and doing it right.

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Volker Lendecke
On Fri, Mar 07, 2008 at 05:02:00PM +0100, Dragan Krnic wrote:
> Volker, can you please look at it and see if you can suggest a fix?

Looking at it.

Volker

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Volker Lendecke
In reply to this post by Dragan Krnic-2
On Fri, Mar 07, 2008 at 05:02:00PM +0100, Dragan Krnic wrote:

> Volker, can you please look at it and see if you can suggest a fix?

Can you try the attached patch? This fixes it for me.

Volker

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

look (542 bytes) Download Attachment
attachment1 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Dragan Krnic-2
On 3/7/08, Volker Lendecke <[hidden email]> wrote:
> On Fri, Mar 07, 2008 at 05:02:00PM +0100, Dragan Krnic wrote:
>
>> Volker, can you please look at it and see if you can suggest a fix?
>
> Can you try the attached patch? This fixes it for me.

Thank you, Volker.
I'll try it out (takes some time to get all the bits and compile).
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Dragan Krnic-2
On 3/10/08, Dragan Krnic <[hidden email]> wrote:
> On 3/7/08, Volker Lendecke <[hidden email]> wrote:
>> On Fri, Mar 07, 2008 at 05:02:00PM +0100, Dragan Krnic wrote:
>>
>>> Volker, can you please look at it and see if you can suggest a fix?
>>
>> Can you try the attached patch? This fixes it for me.
>
> Thank you, Volker.
> I'll try it out (takes some time to get all the bits and compile).

It didn't take so much time and it works.
Thank you, Volker.
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Volker Lendecke
On Mon, Mar 10, 2008 at 11:33:17PM +0100, Dragan Krnic wrote:

> On 3/10/08, Dragan Krnic <[hidden email]> wrote:
> > On 3/7/08, Volker Lendecke <[hidden email]> wrote:
> >> On Fri, Mar 07, 2008 at 05:02:00PM +0100, Dragan Krnic wrote:
> >>
> >>> Volker, can you please look at it and see if you can suggest a fix?
> >>
> >> Can you try the attached patch? This fixes it for me.
> >
> > Thank you, Volker.
> > I'll try it out (takes some time to get all the bits and compile).
>
> It didn't take so much time and it works.
Now you should report the bug to MS :-)

You will very likely see the same behaviour when you run
against OS/2 or Win95 as a server :-)

Volker

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Dragan Krnic-2
On 3/10/08, Volker Lendecke <[hidden email]> wrote:

> On Mon, Mar 10, 2008 at 11:33:17PM +0100, Dragan Krnic wrote:
>> On 3/10/08, Dragan Krnic <[hidden email]> wrote:
>>> On 3/7/08, Volker Lendecke <[hidden email]> wrote:
>>>> On Fri, Mar 07, 2008 at 05:02:00PM +0100, Dragan Krnic wrote:
>>>>
>>>>> Volker, can you please look at it and see if you can suggest a fix?
>>>>
>>>> Can you try the attached patch? This fixes it for me.
>>>
>>> Thank you, Volker.
>>> I'll try it out (takes some time to get all the bits and compile).
>>
>> It didn't take so much time and it works.
>
> Now you should report the bug to MS :-)
>
> You will very likely see the same behaviour when you run
> against OS/2 or Win95 as a server :-)

I will, but is it really a bug?
Or was it designed to hurt Samba?

A little bit off topic, but I had another problem with XP/x64
in connection with Oracle. For quite some time Oracle was
effectively disabled under XP/x64 due to the fact that the
32-bit paths to executables and libraries contained brackets
in the string. Even today there is no direct way to configure
an Oracle server as a Data Source. Might be an innocent
lack of due dilligence but when it hurts the competition so
bad, one wonders.
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Volker Lendecke
On Tue, Mar 11, 2008 at 12:53:19PM +0100, Dragan Krnic wrote:
> I will, but is it really a bug?
> Or was it designed to hurt Samba?

Naaa, a handle leak is definitely a bug. I never believed
that Microsoft puts in stuff to annoy Samba. The worst I
could believe is that they choose some nasty timing for
announcements, but I don't think they ever put stuff in to
explicitly break Samba. This does not say that they
deliberatly neglect Samba in their testing and that they
might have been happy in the past about the fallout when
they break us by accident, but directly nasty -- no.

Volker

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: WinXP/x64 - MFC CFile objects leak parent directory handles

Dragan Krnic-2
On 3/11/08, Volker Lendecke <[hidden email]> wrote:

> On Tue, Mar 11, 2008 at 12:53:19PM +0100, Dragan Krnic wrote:
> > I will, but is it really a bug?
> > Or was it designed to hurt Samba?
>
> Naaa, a handle leak is definitely a bug. I never believed
> that Microsoft puts in stuff to annoy Samba. The worst I
> could believe is that they choose some nasty timing for
> announcements, but I don't think they ever put stuff in to
> explicitly break Samba. This does not say that they
> deliberatly neglect Samba in their testing and that they
> might have been happy in the past about the fallout when
> they break us by accident, but directly nasty -- no.

By the way, a colleague of mine who was bothered by
this problem (MFC Cfile objects leaking parent dir handles)
found out that this problem only started with "MFC42.dll" in
Version 6.6, which is installed in both "System32" and in
"SysWoW64" subdirs of an XP/x64. He tried to replace it
with the version 6.2, which is usually part of XP/ia32,
but every time he deletes it or overwrites it, when he reboots
the version 6.6 is again there.

In short - by putting the "MFC42.dll" version 6.2 in the
same directory with the executable, e.g. "Tester.exe",
the problem can also be solved but your patch is a much
cleaner solution, especially knowing that it is part of the
new Samba 3.0.28a.

Thank you very much.

Regards
Dragan
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba
Loading...