Don't change code when runtime conditions evolve.Just give more RAM to the bot and it's over.
Envoyé depuis Yahoo Mail pour Android
Le jeu. j sept. PM à 18:01, Thomas Faber (JIRA)<noreply(a)reactos.org> a écrit :
[ https://jira.reactos.org/browse/CORE-12020?page=com.atlassian.jira.plugin.s… ]
Thomas Faber commented on CORE-12020:
-------------------------------------
First stage is extremely heavy on memory due to inf parsing. One thing that helped in a similar situation was to separate caroots.inf from registry.inf and have it parsed separately. We should probably do that in trunk...
> We're not able to perform DPH test runs anymore
> -----------------------------------------------
>
> Key: CORE-12020
> URL: https://jira.reactos.org/browse/CORE-12020
> Project: Core ReactOS
> Issue Type: Bug
> Reporter: Amine Khaldi
> Assignee: Bug Zilla
> Labels: REGRESSION
>
> https://build.reactos.org/builders/Test%20KVM/builds/15147/steps/test/logs/…
> https://jira.reactos.org/secure/attachment/37125/ was used with patchbot.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Ros-bugs mailing list
Ros-bugs(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-bugs
Hi all,
Back in April, our server farm used for building had to leave its
hosting site (cf.
https://reactos.org/archives/public/ros-dev/2016-April/017775.html). A
single server was set up at the new site and I estimated to have our old
server farm back up by May or June.
Unfortunately, this still hasn't happened. Our server farm is still at
its old location and I cannot give a timeframe when it will finally be
shipped to the new location.
As we cannot wait forever for this to happen, I put up the old Windows
Home Server VM on our single new server and reintegrated it into
BuildBot ("Test WHS" builder).
Its performance won't match the former one for sure. Instead of 4GB of
RAM, it's currently at mere 1GB and it builds on HDD instead of
RAM-Disk. Nevertheless, it should be fully operational at least.
If this works out well, I'll see if I can also get our Win7 builder up
again. This would give us "Build GCCWin_x86", "Build MSVC_x64" and
"Build MSVC_x86".
I cannot resurrect the VMware and VBox testers right now though. This
will definitely need another machine. Will look after this in October.
Maybe we can also get a RAM upgrade for the existing machine to enable
building on RAM Disks again.
Cheers,
Colin
On 2016-08-28 19.00, ros-dev-request(a)reactos.org wrote:
> Subject:
> Re: [ros-dev] [ros-diffs] [gadamopoulos] 72398: [SHELL32] - Fail to
> delete any file if one is invalid. - Patch by andy-123 CORE-9959
> From:
> Thomas Faber <thomas.faber(a)reactos.org>
> Date:
> 2016-08-28 15.42
>
> To:
> ros-dev(a)reactos.org
>
>
> On 2016-08-20 11:43,gadamopoulos@svn.reactos.org wrote:
>> >--- trunk/reactos/dll/win32/shell32/shlfileop.cpp [iso-8859-1] (original)
>> >+++ trunk/reactos/dll/win32/shell32/shlfileop.cpp [iso-8859-1] Sat Aug 20 09:43:09 2016
>> >@@ -1480,6 +1480,19 @@
>> > return 0;
>> > }
>> >
>> >+ /* Check files. Do not delete one if one file does not exists */
>> >+ for (i = 0; i < flFrom->dwNumFiles; i++)
>> >+ {
>> >+ fileEntry = &flFrom->feFiles[i];
>> >+
>> >+ if ((HANDLE)fileEntry->attributes == INVALID_HANDLE_VALUE)
> What's wrong with INVALID_FILE_ATTRIBUTES?
Fully agree with Thomas.. That is wrong.. Attributes are not handles.
Further, this replicates the unacceptable behavior of the Windows shell,
whereby an entire list of files is dropped when just one fail.
I've argued, some years ago, that such lists should be continued,
ideally adding failed files to a "failed" list to be presented to the user.
You can *not* make any valid assumption of whether other files in the list
will fail just because one of them doesn't exist, or cant be moved because
it's locked, or whatever.
That you are currently writing on this code gives you a good opportunity
to make our shell better than Microsoft's in this regard.
Best Regards
// Neo
>
>> >+ {
>> >+ // This is a windows 2003 server specific value which has been removed.
>> >+ // Later versions of windows return ERROR_FILE_NOT_FOUND.
>> >+ return ERROR_SHELL_INTERNAL_FILE_NOT_FOUND;
>> >+ }
>> >+ }
>> >+
>> > for (i = 0; i < flFrom->dwNumFiles; i++)
>> > {
>> > bPathExists = TRUE;
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]
I've seen like 4 people change this stuff recently and not one of them
got it 100% right.
So here are the rules for how to use probes and SEH:
* Probe pointers before accessing them. This ensures you're not reading
kernel mode memory (and does pretty much nothing else)
* Never access user mode pointers outside of SEH. The application
controls its address space, so protection, physical memory mapping
and contents can change out from under you at any point. For most
purposes, MmProbeAndLockPages is the only way to get around this.
* Sometimes there is no alternative to copying data to kernel memory.
If there is a pointer stored in user mode memory, you need a copy of
it because you can't rely on it not changing after your probe (even
if you lock down the memory).
* In case of an exception you usually want to return the exception code.
There are exceptions (heh) to this rule, but if you think you've
found one, better be sure and show it with a test.
* If you make a pool allocation whose size is directly influenced by
user mode input, there's a good chance you'll want to use
ExAllocatePoolWithQuotaTag
In particular this means:
* Probing something or accessing it once does not save you from using
SEH every single time you access the user mode memory
* Probing UserModePointer->StructMemberPointer is never correct, you
need to make a copy of the struct or that particular member, since
the memory can change
* The ProbeForReadUnicodeString function is not useful unless you use
its return value
Hope this helps. Thanks for hanging in there.
-T
On 2016-09-11 18:13, dchapyshev(a)svn.reactos.org wrote:
> Author: dchapyshev
> Date: Sun Sep 11 16:13:46 2016
> New Revision: 72655
>
> URL: http://svn.reactos.org/svn/reactos?rev=72655&view=rev
> Log:
> [NtUser] Try to fix tests for user32:EnumDisplaySettings
>
> Modified:
> trunk/reactos/win32ss/user/ntuser/display.c
>
> Modified: trunk/reactos/win32ss/user/ntuser/display.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/displa…
> ==============================================================================
> --- trunk/reactos/win32ss/user/ntuser/display.c [iso-8859-1] (original)
> +++ trunk/reactos/win32ss/user/ntuser/display.c [iso-8859-1] Sun Sep 11 16:13:46 2016
> @@ -443,7 +443,7 @@
> {
> /* No device found */
> ERR("No PDEV found!\n");
> - return STATUS_UNSUCCESSFUL;
> + return STATUS_INVALID_PARAMETER_1;
> }
>
> *ppdm = ppdev->pdmwDev;
> @@ -474,7 +474,7 @@
> {
> /* No device found */
> ERR("No device found!\n");
> - return STATUS_UNSUCCESSFUL;
> + return STATUS_INVALID_PARAMETER_1;
> }
>
> iFoundMode = 0;
> @@ -571,13 +571,18 @@
>
> _SEH2_TRY
> {
> - ProbeForWrite(lpDevMode, sizeof(DEVMODEW), 1);
> + ProbeForRead(lpDevMode, sizeof(DEVMODEW), 1);
> +
> + cbSize = lpDevMode->dmSize;
> + cbExtra = lpDevMode->dmDriverExtra;
> +
> + ProbeForWrite(lpDevMode, cbSize + cbExtra, 1);
> }
> _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
> {
> _SEH2_YIELD(return _SEH2_GetExceptionCode());
> }
> - _SEH2_END
> + _SEH2_END;
>
> if (lpDevMode->dmSize != sizeof(DEVMODEW))
> {
> @@ -586,31 +591,30 @@
>
> if (pustrDevice)
> {
> - if (pustrDevice->Buffer == NULL || pustrDevice->Length == 0)
> - {
> - Status = STATUS_INVALID_PARAMETER_1;
> - }
> -
> /* Initialize destination string */
> RtlInitEmptyUnicodeString(&ustrDevice, awcDevice, sizeof(awcDevice));
>
> _SEH2_TRY
> {
> /* Probe the UNICODE_STRING and the buffer */
> - ProbeForRead(pustrDevice, sizeof(UNICODE_STRING), 1);
> - ProbeForRead(pustrDevice->Buffer, pustrDevice->Length, 1);
> + ProbeForReadUnicodeString(pustrDevice);
> +
> + if (!pustrDevice->Length || !pustrDevice->Buffer)
> + ExRaiseStatus(STATUS_NO_MEMORY);
> +
> + ProbeForRead(pustrDevice->Buffer, pustrDevice->Length, sizeof(UCHAR));
>
> /* Copy the string */
> RtlCopyUnicodeString(&ustrDevice, pustrDevice);
> }
> _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
> {
> - _SEH2_YIELD(return _SEH2_GetExceptionCode());
> - }
> - _SEH2_END
> + _SEH2_YIELD(return STATUS_INVALID_PARAMETER_1);
> + }
> + _SEH2_END;
>
> pustrDevice = &ustrDevice;
> - }
> + }
>
> /* Acquire global USER lock */
> UserEnterShared();
> @@ -642,11 +646,6 @@
> /* Copy some information back */
> _SEH2_TRY
> {
> - ProbeForRead(lpDevMode, sizeof(DEVMODEW), 1);
> - cbSize = lpDevMode->dmSize;
> - cbExtra = lpDevMode->dmDriverExtra;
> -
> - ProbeForWrite(lpDevMode, cbSize + cbExtra, 1);
> /* Output what we got */
> RtlCopyMemory(lpDevMode, pdm, min(cbSize, pdm->dmSize));
>
> @@ -663,13 +662,6 @@
> Status = _SEH2_GetExceptionCode();
> }
> _SEH2_END;
> - }
> - else
> - {
> - if (Status == STATUS_UNSUCCESSFUL)
> - {
> - Status = STATUS_INVALID_PARAMETER_1;
> - }
> }
>
> return Status;
>
>