[ros-dev] [ros-diffs] [tfaber] 65269: [FASTFAT] - VfatCleanupFile: do not dereference the FCB when closing the volume file object. ObDereferenceObject already causes an IRP_MJ_CLOSE request to be sent, which dereference...

[Pierre Schweitzer]

I agree there shouldn't have any dereference during cleanup.
But, this is actually fixing the leak in renaming process (only
happens). That one is pretty hard to track. Jérôme and I had bad moments
on that one.

This leak doesn't happen in normal working of the FSD, but only in
renaming operations. Fixing it would likely fix most (all?) of the
renaming issues.

On 05/11/2014 20:53, Thomas Faber wrote:
> Oh... Jérôme, I only just saw that you added this in r65140...
> And my change does break the msi tests again. :\
> 
> Any idea what's going wrong here?
> I'm relatively certain my change is correct because
> vfatFCBInitializeCacheFromVolume takes one reference, and VfatCloseFile
> invoked via ObDereferenceObject will remove that reference again.
> 
> So apparently we're leaking a directory reference somewhere else? :(
> Not sure if your previous investigation into this issue can provide any
> pointers. Otherwise I'll have to start digging for the leak all over
> again...
> 
> Thanks.
> -Thomas
> 
> 
> On 2014-11-05 19:52, tfaber at svn.reactos.org wrote:
>> --- trunk/reactos/drivers/filesystems/fastfat/cleanup.c	[iso-8859-1] (original)
>> +++ trunk/reactos/drivers/filesystems/fastfat/cleanup.c	[iso-8859-1] Wed Nov  5 18:52:11 2014
>> @@ -92,7 +92,6 @@
>>                  pFcb->FileObject = NULL;
>>                  CcUninitializeCacheMap(tmpFileObject, NULL, NULL);
>>                  ObDereferenceObject(tmpFileObject);
>> -                vfatReleaseFCB(IrpContext->DeviceExt, pFcb);
>>              }
>>  
>>              CcPurgeCacheSection(FileObject->SectionObjectPointer, NULL, 0, FALSE);
>>
>>


-- 
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3968 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.reactos.org/pipermail/ros-dev/attachments/20141105/0c680b87/attachment.bin>