Ros-dev September 2012

ros-dev@reactos.org

13 participants
23 discussions

Fwd: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test
by caemyr＠myopera.com 02 Sep '12

02 Sep '12

This one is caused by rev 57225: Backtrace: http://www.reactos.org/paste/index.php/10472/ Please fix ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Subject: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test Date: Sun, 02 Sep 2012 22:50:06 +0000 The Buildbot has finished a build on builder Windows_AMD64_1 VBox-Test while building ReactOS. Full details are available at: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/6492 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_2 Build Reason: Triggerable(Windows_AMD64_1 VBox-Test Trigger) Build Source Stamp: 57225 Blamelist: ion BUILD FAILED: failed test sincerely, -The Buildbot -- With best regards Caemyr

1 0

Problem with dbgwin revisions from Windows builder
by caemyr＠myopera.com 02 Sep '12

02 Sep '12

Hiya R3ddr4g0n reported to me that all recent revisions uploaded to iso.reactos.org are not correct. Instead of given revision, all the builds are reporting to be rev 57150. After a quick check, i downloaded bootcd-57221-dbgwin.iso and checked its SHA1: should be 56d2190610e8a1f650faa3c6a6a8348f89d1fa1b but happened to be: f97ac4aba0e5ceed3b5beae3d7ab2bc2c7600fab - which is indeed the same checksum as for x86_CMake-57150 The possible clue from the upload script: bash: rsync: command not found rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at /home/lapo/package/rsync-3.0.8-1/src/rsync-3.0.8/io.c(601) [sender=3.0.8] * Done. * Remotely compressing bootcd-57219-dbgwin... Now, Colin may recall that i was strongly against using fancy tricks for sending the revs instead of simply archiving them locally and uploading afterwards. This way with rsync was supposed to be saving bit of bandwidth. Now we have to reupload at least all since 57150, unless you can use the fancy tricks to spot the same iso files. Great thing we can save a little bit of bandwidth but waste time to fix it afterwards. Accoring to the reporter: [21:45:37] <r3ddr4g0n> for sure from 57115 to 57221 If you still think this methode is saving us anything, please reckon that a single view of testbot log means downloading a few megabytes of text at least. I`m stopping the uploads until the problem is resolved in a way to prevent it from happening again. -- With best regards Caemyr

2 1

Re: [ros-dev] [ros-diffs] [ion] 57215: [NTOSKRNL]: Do not return data in failure cases in NtProtectVirtualMemory. [NTOSKRNL]: No longer support non-ARM3 sections in NtProtectVirtualMemory, as the only OS calls were already ...
by Thomas Faber 02 Sep '12

02 Sep '12

Hi! On 02.09.2012 03:17, ion(a)svn.reactos.org wrote: > Modified: trunk/reactos/ntoskrnl/mm/ARM3/virtual.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/virtual.c… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Sun Sep 2 01:17:42 2012 > @@ -3668,15 +3795,50 @@ > } > > // > - // Assert on the things we don't yet support > - // > - ASSERT(ZeroBits == 0); > - ASSERT((AllocationType& MEM_LARGE_PAGES) == 0); > - ASSERT((AllocationType& MEM_PHYSICAL) == 0); > - ASSERT((AllocationType& MEM_WRITE_WATCH) == 0); > - ASSERT((AllocationType& MEM_TOP_DOWN) == 0); > - ASSERT((AllocationType& MEM_RESET) == 0); > - ASSERT(Process->VmTopDown == 0); > + // Fail on the things we don't yet support > + // > + if (ZeroBits != 0) > + { > + DPRINT1("Zero bits not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_LARGE_PAGES) == 1) > + { > + DPRINT1("MEM_LARGE_PAGES not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_PHYSICAL) == 1) > + { > + DPRINT1("MEM_PHYSICAL not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_WRITE_WATCH) == 1) > + { > + DPRINT1("MEM_WRITE_WATCH not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_TOP_DOWN) == 1) > + { > + DPRINT1("MEM_TOP_DOWN not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_RESET) == 1) > + { > + DPRINT1("MEM_RESET not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } These guys won't work, you need != 0 or == MEM_BLAH -Thomas

1 0

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 September 2012