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, tfa...@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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
