Ros-dev

ros-dev@reactos.org

5791 discussions

Re: [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...
by Thomas Faber 05 Nov '14

05 Nov '14

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(a)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); > >

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 65255: Merged revision(s) 62353, 62531-62532, 62853, 64152, 64173-64174 from branches/kernel-fun/reactos: [NTOSKRNL] Implement SystemPrioritySeperation case in NtSetSystemInformation ......
by Thomas Faber 04 Nov '14

04 Nov '14

On 2014-11-04 21:47, tkreuzer(a)svn.reactos.org wrote: > --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Tue Nov 4 20:47:18 2014 > @@ -1580,6 +1580,8 @@ > if (OpenPacket.ParseCheck != TRUE) > { > /* Parse failed */ > + DPRINT1("IopQueryAttributesFile failed for '%wZ' with 0x%lx\n", > + ObjectAttributes->ObjectName, Status); > return Status; > } > else This one seems to be super noisy on testbot.

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 65210: [NTOS/PS] - Do not leak a reference to the process object when setting quotas.
by Timo Kreuzer 03 Nov '14

03 Nov '14

Doesn't this change Windows behaviour? No, luckily it does not change *Windows* behaviour. It does not even change ReactOS behaviour, but only, because it was already broken before. Since MS implemented this function in an arbitrary and hard to comprehend way, we need to follow this pattern. This means, the function must not fail on process reference failure, unless certain conditions are met, otherwise we will fail with the wrong Status code. To fix the situation, we could remember the fact that the process couldn't be referenced (possibly by setting Process to NULL) and later check that after other checks were done. The alternative is referencing the process individually in each and every case, which will make the function even more huge and does not really help with it's readability. Or we can factor our each case and implement it as a separate function. It would add a lot of code duplication, but might help a bit with readability and maintainability. Am 03.11.2014 10:52, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Nov 3 09:52:08 2014 > New Revision: 65210 > > URL: http://svn.reactos.org/svn/reactos?rev=65210&view=rev > Log: > [NTOS/PS] > - Do not leak a reference to the process object when setting quotas. > > Modified: > trunk/reactos/ntoskrnl/include/internal/ps.h > trunk/reactos/ntoskrnl/ps/query.c > trunk/reactos/ntoskrnl/ps/quota.c > > Modified: trunk/reactos/ntoskrnl/include/internal/ps.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/ps.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/ps.h [iso-8859-1] Mon Nov 3 09:52:08 2014 > @@ -303,7 +303,7 @@ > NTSTATUS > NTAPI > PspSetQuotaLimits( > - _In_ HANDLE ProcessHandle, > + _In_ PEPROCESS Process, > _In_ ULONG Unused, > _In_ PVOID QuotaLimits, > _In_ ULONG QuotaLimitsLength, > > Modified: trunk/reactos/ntoskrnl/ps/query.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/query.c?rev=65… > ============================================================================== > --- trunk/reactos/ntoskrnl/ps/query.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ps/query.c [iso-8859-1] Mon Nov 3 09:52:08 2014 > @@ -1528,6 +1528,7 @@ > /* Validate the number */ > if ((BasePriority > HIGH_PRIORITY) || (BasePriority <= LOW_PRIORITY)) > { > + ObDereferenceObject(Process); > return STATUS_INVALID_PARAMETER; > } > > @@ -1918,11 +1919,12 @@ > > case ProcessQuotaLimits: > > - return PspSetQuotaLimits(ProcessHandle, > + Status = PspSetQuotaLimits(Process, > 1, > ProcessInformation, > ProcessInformationLength, > PreviousMode); > + break; > > case ProcessWorkingSetWatch: > DPRINT1("WS watch not implemented\n"); > > Modified: trunk/reactos/ntoskrnl/ps/quota.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/quota.c?rev=65… > ============================================================================== > --- trunk/reactos/ntoskrnl/ps/quota.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ps/quota.c [iso-8859-1] Mon Nov 3 09:52:08 2014 > @@ -292,14 +292,13 @@ > NTSTATUS > NTAPI > PspSetQuotaLimits( > - _In_ HANDLE ProcessHandle, > + _In_ PEPROCESS Process, > _In_ ULONG Unused, > _In_ PVOID QuotaLimits, > _In_ ULONG QuotaLimitsLength, > _In_ KPROCESSOR_MODE PreviousMode) > { > QUOTA_LIMITS_EX CapturedQuotaLimits; > - PEPROCESS Process; > PEPROCESS_QUOTA_BLOCK QuotaBlock, OldQuotaBlock; > BOOLEAN IncreaseOkay; > KAPC_STATE SavedApcState; > @@ -368,19 +367,6 @@ > } > _SEH2_END; > > - /* Reference the process */ > - Status = ObReferenceObjectByHandle(ProcessHandle, > - PROCESS_SET_QUOTA, > - PsProcessType, > - PreviousMode, > - (PVOID*)&Process, > - NULL); > - if (!NT_SUCCESS(Status)) > - { > - DPRINT1("Failed to reference process handle: 0x%lx\n", Status); > - return Status; > - } > - > /* Check the caller changes the working set size limits */ > if ((CapturedQuotaLimits.MinimumWorkingSetSize != 0) && > (CapturedQuotaLimits.MaximumWorkingSetSize != 0)) > @@ -418,7 +404,6 @@ > /* Check if the caller has the required privilege */ > if (!SeSinglePrivilegeCheck(SeIncreaseQuotaPrivilege, PreviousMode)) > { > - ObDereferenceObject(Process); > return STATUS_PRIVILEGE_NOT_HELD; > } > > @@ -460,8 +445,6 @@ > Status = STATUS_SUCCESS; > } > > - /* Dereference the process and return the status */ > - ObDereferenceObject(Process); > return Status; > } > > > >

1 0

Fezile server downtime this evening
by Colin Finck 03 Nov '14

03 Nov '14

Hi all, Jan and I will finally install the remote management card in Fezile this evening and verify the cabling of our UPS systems. This will cause a short downtime of the Fezile server along with its testslaves, cppcheck, Doxygen, Git and iso.reactos.org. In case we notice a fault in UPS cabling, we may also be required to temporarily shut down other servers, replug their power cables and boot them up again. This may cause very short downtimes as well. After this measure, we will be able to totally manage this important server remotely, even if its OS has failed at some point. Proper UPS cabling also ensures smooth operations in case of sudden power outages. Thanks for your understanding! Cheers, Colin

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 65166: [NTFS] Simplify buffer size management in GetNtfsFileRecord(). As tests shown, Windows doesn't care about the real size of the file record and expects the caller to pass the co...
by Thomas Faber 01 Nov '14

01 Nov '14

On 2014-11-01 11:02, pschweitzer(a)svn.reactos.org wrote: > - OutputBuffer->FileRecordLength = FileRecord->BytesInUse; > - RtlCopyMemory(OutputBuffer->FileRecordBuffer, FileRecord, FileRecord->BytesInUse); > + OutputBuffer->FileRecordLength = DeviceExt->NtfsInfo.BytesPerFileRecord; > + RtlCopyMemory(OutputBuffer->FileRecordBuffer, FileRecord, DeviceExt->NtfsInfo.BytesPerFileRecord); Wait, now there's no check against OutputBufferLength at all? It should at least be min(DeviceExt->NtfsInfo.BytesPerFileRecord, Stack->Parameters.FileSystemControl.OutputBufferLength) in the memcpy size. Or am I missing something?

2 3

Re: [ros-dev] [ros-diffs] [jgardou] 65140: [FASTFAT] - Fix renaming files in case the target file already exists. - Plug a few reference count leaks on FCBs. CORE-8660 #comment fixed in r65140 #resolve CORE-8633 #comment fi...
by Pierre Schweitzer 31 Oct '14

31 Oct '14

Warm thanks for debugging this issue Jérôme. I do value your help. This should unlock many autoupdating apps in ReactOS. Thanks again. On 31/10/2014 12:04, jgardou(a)svn.reactos.org wrote: > Author: jgardou > Date: Fri Oct 31 11:04:12 2014 > New Revision: 65140 > > URL: http://svn.reactos.org/svn/reactos?rev=65140&view=rev > Log: > [FASTFAT] > - Fix renaming files in case the target file already exists. > - Plug a few reference count leaks on FCBs. > CORE-8660 #comment fixed in r65140 #resolve > CORE-8633 #comment fixed in r65140 #resolve > CORE-4758 #comment fixed in r65140 #resolve > > Modified: > trunk/reactos/drivers/filesystems/fastfat/cleanup.c > trunk/reactos/drivers/filesystems/fastfat/create.c > trunk/reactos/drivers/filesystems/fastfat/finfo.c > > Modified: trunk/reactos/drivers/filesystems/fastfat/cleanup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] Fri Oct 31 11:04:12 2014 > @@ -92,6 +92,7 @@ > pFcb->FileObject = NULL; > CcUninitializeCacheMap(tmpFileObject, NULL, NULL); > ObDereferenceObject(tmpFileObject); > + vfatReleaseFCB(IrpContext->DeviceExt, pFcb); > } > > CcPurgeCacheSection(FileObject->SectionObjectPointer, NULL, 0, FALSE); > > Modified: trunk/reactos/drivers/filesystems/fastfat/create.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/create.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/create.c [iso-8859-1] Fri Oct 31 11:04:12 2014 > @@ -365,7 +365,6 @@ > DPRINT("'%wZ'\n", &FileObject->RelatedFileObject->FileName); > > *ParentFcb = FileObject->RelatedFileObject->FsContext; > - vfatGrabFCB(DeviceExt, *ParentFcb); > } > else > { > > Modified: trunk/reactos/drivers/filesystems/fastfat/finfo.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/finfo.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/finfo.c [iso-8859-1] Fri Oct 31 11:04:12 2014 > @@ -396,41 +396,53 @@ > /* If it exists */ > if (NT_SUCCESS(Status)) > { > + DPRINT("Target file %wZ exists. FCB Flags %08x\n", NewName, TargetFcb->Flags); > /* Check whether we are allowed to replace */ > if (ReplaceIfExists) > { > /* If that's a directory or a read-only file, we're not allowed */ > - if (vfatFCBIsDirectory(TargetFcb) || ((*TargetFcb->Attributes & FILE_ATTRIBUTE_READONLY) == FILE_ATTRIBUTE_READONLY)); > - { > + if (vfatFCBIsDirectory(TargetFcb) || ((*TargetFcb->Attributes & FILE_ATTRIBUTE_READONLY) == FILE_ATTRIBUTE_READONLY)) > + { > + DPRINT("And this is a readonly file!\n"); > vfatReleaseFCB(DeviceExt, *ParentFCB); > *ParentFCB = NULL; > vfatReleaseFCB(DeviceExt, TargetFcb); > return STATUS_OBJECT_NAME_COLLISION; > } > > - /* Attempt to flush (might close the file) */ > - if (!MmFlushImageSection(TargetFcb->FileObject->SectionObjectPointer, MmFlushForDelete)) > - { > + > + /* If we still have a file object, close it. */ > + if (TargetFcb->FileObject) > + { > + if (!MmFlushImageSection(TargetFcb->FileObject->SectionObjectPointer, MmFlushForDelete)) > + { > + DPRINT("MmFlushImageSection failed.\n"); > + vfatReleaseFCB(DeviceExt, *ParentFCB); > + *ParentFCB = NULL; > + vfatReleaseFCB(DeviceExt, TargetFcb); > + return STATUS_ACCESS_DENIED; > + } > + > + TargetFcb->FileObject->DeletePending = TRUE; > + VfatCloseFile(DeviceExt, TargetFcb->FileObject); > + } > + > + /* If we are here, ensure the file isn't open by anyone! */ > + if (TargetFcb->OpenHandleCount != 0) > + { > + DPRINT("There are still open handles for this file.\n"); > vfatReleaseFCB(DeviceExt, *ParentFCB); > *ParentFCB = NULL; > vfatReleaseFCB(DeviceExt, TargetFcb); > return STATUS_ACCESS_DENIED; > } > > - /* If we are, ensure the file isn't open by anyone! */ > - if (TargetFcb->OpenHandleCount != 0) > - { > - vfatReleaseFCB(DeviceExt, *ParentFCB); > - *ParentFCB = NULL; > - vfatReleaseFCB(DeviceExt, TargetFcb); > - return STATUS_ACCESS_DENIED; > - } > - > /* Effectively delete old file to allow renaming */ > + DPRINT("Effectively deleting the file.\n"); > VfatDelEntry(DeviceExt, TargetFcb, NULL); > - vfatGrabFCB(DeviceExt, *ParentFCB); > vfatReleaseFCB(DeviceExt, TargetFcb); > *Deleted = TRUE; > + return STATUS_SUCCESS; > } > else > { > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 65133: [LOGOFF] * Plug some leaks. CIDs 716284 and 716285. CORE-7975
by Thomas Faber 31 Oct '14

31 Oct '14

Hey, On 2014-10-31 10:22, akhaldi(a)svn.reactos.org wrote: > @@ -90,6 +91,7 @@ > //Invalid parameter detected > if (AllocAndLoadString(&lpIllegalMsg, GetModuleHandle(NULL), IDS_ILLEGAL_PARAM)) > _putts(lpIllegalMsg); > + LocalFree(lpIllegalMsg); > return FALSE; > } > } > This needs braces. Both puts and LocalFree should only be executed if AllocAndLoadString succeeds (but return FALSE in either case). Thanks!

1 0

BuildBot changes
by Colin Finck 30 Oct '14

30 Oct '14

Hi all, As you can see in project-tools SVN, I've improved our Bash scripts for Buildslaves. They're now also usable under Windows (in a Cygwin environment) and I'm already doing this on our new Windows Buildslave Carrier-Win7. Bash on Windows may look hacky at first, but it's definitely more comfortable than Batch! Moreover, we now only have a single version of build scripts to maintain for all our Buildslaves! This also involved some naming changes on the existing slaves to maintain a consistent scheme. Tell me if anything broke. Bringing all desired Windows builders back will still take some time. I've only started with a RosBE-Windows based one right now and I need your help here: For some reason, VirtualBox 4.3.18 (used for reg-testing) doesn't want to run headless. I can do a 'runas /user:buildbot VBoxManage controlvm "ReactOS Testbot" poweroff' in a CMD and it will work well. The very same command executed through BuildBot ends with: ==================================================================== VBoxManage.exe: error: Failed to create the VirtualBox object! VBoxManage.exe: error: Code E_ACCESSDENIED (0x80070005) - General access denied error (extended info not available) VBoxManage.exe: error: Most likely, the VirtualBox COM server is not running or failed to start. ==================================================================== See http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/6/step… VBoxSVC.log isn't touched when BuildBot tries this command, so I have no additional information. Haven't found a solution yet, so I'm asking here if any of the VBox experts know what could be going wrong. Cheers, Colin

5 10

Do not waste 65432 and 65536 GET!
by Alexander Rechitskiy 30 Oct '14

30 Oct '14

1 0

Status Meeting (October 2014)
by Aleksey Bragin 29 Oct '14

29 Oct '14

Hello, Let me invite you to the monthly status meeting taking place 30th of October, 19:00 UTC (that's tomorrow!). IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. Regards, Aleksey Bragin

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev