Ros-dev March 2012

ros-dev@reactos.org

23 participants
32 discussions

Re: [ros-dev] [ros-diffs] [cgutman] 56069: [NTOSKRNL] - Fix the unload path - This does expose some bugs: 2 cont-able assertions in ARM3 after unplugging a USB storage device (during usbstor unload), HID unload doesn't seem...
by Cameron Gutman 06 Mar '12

06 Mar '12

[NTOSKRNL] - Fix the unload path - This does expose some bugs: 2 cont-able assertions in ARM3 after unplugging a USB storage device (during usbstor unload), HID unload doesn't seem to work correctly (somebody still has references to the devices), other issues may pop up too I've tracked this issue down to using loader heap to allocate the LDR data entry (which gets freed by the kernel during init). This makes it invalid when we go to read the module object when we unload it, causing a crash. I'm not sure how to move forward from here but the changes needed are in FreeLoader's peloader.c. After fixing that, I'm running into another issue where it appears that LdrEntry->LoadedImports is no longer valid (set for boot drivers during kernel init) so it results in a null pointer dereference. I've confirmed that this crash only occurs when boot loaded drivers are unloaded; any other PnP driver loaded after boot unloads perfectly. Richard (or someone else knowledgeable in the area), if you could take a few minutes to figure this out for me that would be fantastic. Here is the log and backtrace after I fixed the LDR data entry allocation type: (C:\Users\Cam\reactos\trunk\ntoskrnl\io\iomgr\device.c:447) Unloading driver '\Driver\usbstor' (automatic) (C:\Users\Cam\reactos\trunk\ntoskrnl\io\iomgr\driver.c:61) Deleting driver object '\Driver\usbstor' (C:\Users\Cam\reactos\trunk\ntoskrnl\mm\ARM3\sysldr.c:935) Leaking driver: usbstor.sys Entered debugger on first-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0x00000000 could not be read: Page not present. kdb:> bt Eip: <NTOSKRNL.EXE:b0c71 (ReactOS/ntoskrnl/mm/ARM3/sysldr.c:389 (MiDereferenceImports@4))> Frames: <NTOSKRNL.EXE:b0a7f (ReactOS/ntoskrnl/mm/ARM3/sysldr.c:947 (MmUnloadSystemImage@4))> <NTOSKRNL.EXE:5ce2c (ReactOS/ntoskrnl/io/iomgr/driver.c:80 (IopDeleteDriver@4))> <NTOSKRNL.EXE:d63f5 (ReactOS/ntoskrnl/ob/oblife.c:211 (ObpDeleteObject@8))> <NTOSKRNL.EXE:da790 (ReactOS/ntoskrnl/ob/obref.c:237 (@ObfDereferenceObject@4))> <NTOSKRNL.EXE:59c24 (ReactOS/ntoskrnl/io/iomgr/device.c:61 (IopDeleteDevice@4))> <NTOSKRNL.EXE:d63f5 (ReactOS/ntoskrnl/ob/oblife.c:211 (ObpDeleteObject@8))> <NTOSKRNL.EXE:da790 (ReactOS/ntoskrnl/ob/obref.c:237 (@ObfDereferenceObject@4))> <NTOSKRNL.EXE:73adc (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:1286 (IopSynchronousCall@12))> <NTOSKRNL.EXE:73b23 (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:585 (IopSendRemoveDevice@4))> <NTOSKRNL.EXE:7532a (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:2214 (IopEnumerateDevice))> <NTOSKRNL.EXE:7550c (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:4672 (IoSynchronousInvalidateDeviceRelations@8))> <NTOSKRNL.EXE:75530 (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:889 (IopAsynchronousInvalidateDeviceRelations@8))> <NTOSKRNL.EXE:6a737 (ReactOS/ntoskrnl/io/iomgr/iowork.c:27 (IopWorkItemCallback@4))> <NTOSKRNL.EXE:42056 (ReactOS/ntoskrnl/ex/work.c:162 (ExpWorkerThreadEntryPoint@4))> <NTOSKRNL.EXE:efaca (ReactOS/ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:100d63 (ReactOS/ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:efa66 (ReactOS/ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> Regards, Cameron

1 0

Problems with patchbot/newcc/rosbe
by caemyr＠myopera.com 06 Mar '12

06 Mar '12

After a quick look into your problems with patchbot it seems that vbox scripts were missing some errorlevel checks, which should bail out the test run at prepare stage when ISO was not present (which is the situation when you dont pass the proper revision/id number. Same thing was with newcc1 tests. I added some debug prints so if my current solution wont do its job, i`ll at least know bit more about the problem. By that occasion i found out a problem with current ROSBE - its not emitting proper ERRORLEVEL at the end of the build, due to tee/buildtime/flash/sound playback or any of similar crap that is getting the final ERRORLEVEL value. For main building step i hacked around this issue by simply checking for ISO file at the end and erroring out if its not there. For host building part, this is more complicated. I tried removing the stuff mentioned above, but it still doesnt work. Dreimer: it would be of help if you could fix this problem. -- With best regards Caemyr

4 5

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

06 Mar '12

Sorry for the error spam, had to fix one erroneous check (that forced exiting with errorlevel 0 instead of the proper one). ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Date: Tue, 06 Mar 2012 21:18:43 +0000 Subject: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test 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/5204 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_2 Build Reason: The web-page 'rebuild' button was pressed by 'osiejka': Build Source Stamp: 56063 Blamelist: cgutman BUILD FAILED: failed Initial preparations sincerely, -The Buildbot -- With best regards Caemyr

1 0

Release builds are back
by Pierre Schweitzer 06 Mar '12

06 Mar '12

Hi, release builds will finally be available again. Those will be daily built against most recent head. They will be findable at usual place. For the moment, no new release build is available since release build its broken (cf: http://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/1/steps…). With my best regards, -- Pierre Schweitzer<pierre(a)reactos.org> System Administrator ReactOS Foundation

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 56043: [NEWCC] - Turn NewCC on temporarily for some testing - Patchbot is broken so I had to do it this way :(‏
by Pierre Schweitzer 05 Mar '12

05 Mar '12

Nice try! However it failed on KVM: http://build.reactos.org/builders/Linux_AMD64_1% 20KVM-CMake-Test/builds/255/steps/test/logs/stdio Regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

3 2

Fwd: buildbot failure in ReactOS on CMake_x86_GCCWin Debug
by caemyr＠myopera.com 04 Mar '12

04 Mar '12

Could it be a ccache miss? Failed to read source file: 0 mingw32-make.exe[3]: *** [boot/freeldr/freeldr/frldr16.bin] Error -4 [ 98%] [ 98%] mingw32-make.exe[2]: *** [boot/freeldr/freeldr/CMakeFiles/freeldr.dir/all] Error 2 mingw32-make.exe[2]: *** Waiting for unfinished jobs.... ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Date: Sun, 04 Mar 2012 20:03:52 +0000 Subject: buildbot failure in ReactOS on CMake_x86_GCCWin Debug The Buildbot has finished a build on builder CMake_x86_GCCWin Debug while building ReactOS. Full details are available at: http://build.reactos.org/builders/CMake_x86_GCCWin%20Debug/builds/2966 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_1 Build Reason: scheduler Build Source Stamp: 56010 Blamelist: sir_richard BUILD FAILED: failed building bootcd sincerely, -The Buildbot -- With best regards Caemyr

2 1

Re: [ros-dev] [ros-diffs] [cgutman] 55978: [STORAGE] - Back by popular demand, the storage driver to end all storage drivers, uniata! - I had forgotten how many issues atapi had itself and the hardware compatibility improve...‏
by Pierre Schweitzer 04 Mar '12

04 Mar '12

Hi, this revision actually fixed KVM testbot (ie r55980 was not mandatory). But this has been hidden by two things: - sysreg regression: this has been kicked out by now; - trunk regression: introduced by r55977, it is still present. And results couldn't be sent to testman since rosautotest got messed up and ran same tests several times; Sorry for the issues caused by sysreg regression. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

Re: [ros-dev] buildbot failure in ReactOS on CMake_x86_MSVCWin Debug
by caemyr＠myopera.com 03 Mar '12

03 Mar '12

Cabman error, build was restarted and went fine On Sat, Mar 3, 2012, at 08:26 PM, buildbot(a)reactos.org wrote: > The Buildbot has finished a build on builder CMake_x86_MSVCWin Debug > while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/CMake_x86_MSVCWin%20Debug/builds/596 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Windows_AMD64_1a > > Build Reason: scheduler > Build Source Stamp: 55970 > Blamelist: tkreuzer > > BUILD FAILED: failed building bootcd > > sincerely, > -The Buildbot > -- With best regards Caemyr

1 0

Re: [ros-dev] [ros-builds] Linux_AMD64_1 KVM-CMake-Test: build failed
by Pierre Schweitzer 03 Mar '12

03 Mar '12

This is due to an issue within both ReactOS and sysreg. ReactOS appears not to boot any longer with r55879 on KVM, and crashing during ntoskrnl init on CD. Sysreg is also not catching the crash, nor hitting the timeout and so is not killing the VM. And then, buildbot is unable to start any new test due to the frozen VM. I have killed the frozen VM and restarted HEAD (ie, r55886 testing). If the fix has been really committed with r55880, it should work properly. Will investigate the issue ASAP, to ensure it doesn't happen any more. Le lundi 27 février 2012 à 17:40 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Linux_AMD64_1 KVM-CMake-Test while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Linux_AMD64_1%20KVM-CMake-Test/builds/76 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: Triggerable(Linux_AMD64_1 KVM-CMake-Test Trigger) > Build Source Stamp: 55886 > Blamelist: ion > > BUILD FAILED: failed test > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 1

Re: [ros-dev] buildbot failure in ReactOS on CMake_x86_MSVCWin Debug
by caemyr＠myopera.com 02 Mar '12

02 Mar '12

Cabman failure. Repeated. On Fri, Mar 2, 2012, at 10:24 PM, buildbot(a)reactos.org wrote: > The Buildbot has finished a build on builder CMake_x86_MSVCWin Debug > while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/CMake_x86_MSVCWin%20Debug/builds/566 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Windows_AMD64_1a > > Build Reason: scheduler > Build Source Stamp: 55939 > Blamelist: khornicek > > BUILD FAILED: failed building bootcd > > sincerely, > -The Buildbot > -- With best regards Caemyr

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev March 2012