Ros-dev

ros-dev@reactos.org

5789 discussions

Re: [ros-dev] buildbot exception in ReactOS on Windows_AMD64_1 VBox-Test

by caemyr＠myopera.com

Looks like the crash had locked up the VM hard: loader.c:1019: Test failed: wrong section data (..\..\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ldr3C.tmp (10000000 -> 00011000) (..\..\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: Dynamically Allocated Memory loader.c:599: Test failed: got 0x4 != expected 0x1 loader.c:601: Test failed: 0x4 != PAGE_EXECUTE_WRITECOPY loader.c:627: Test failed: got 0x4 != expected 0x1 loader.c:629: Test failed: 0x4 != PAGE_EXECUTE_WRITECOPY loader.c:645: Test failed: got 0x4 != expected 0x1 loader.c:647: Test failed: 0x4 != PAGE_EXECUTE_WRITECOPY (..\..\ntoskrnl\mm\ARM3\expool.c:274) Entry BlockSize 2, tag fPsR. NextEntry PreviousSize 0, tag *** Fatal System Error: 0x00000019 (0x00000005,0xB0A0EB18,0x00000116,0xB0A0EB08) [7hEntered debugger on embedded INT3 at 0x0008:0x8091ba34. kdb:> bt Eip: <NTOSKRNL.EXE:11ba35 (..\..\lib\rtl\i386\debug_asm.S:46 (_RtlpBreakWithStatusInstruction@0))> Frames: <NTOSKRNL.EXE:80445 (../../ntoskrnl/ke/bug.c:1081 (KeBugCheckWithTf@24))> <NTOSKRNL.EXE:80581 (../../ntoskrnl/ke/bug.c:1405 (KeBugCheckEx@20))> <NTOSKRNL.EXE:964e2 (../../ntoskrnl/mm/ARM3/expool.c:211 (ExpCheckPoolHeader@4))> <NTOSKRNL.EXE:966d3 (../../ntoskrnl/mm/ARM3/expool.c:303 (ExpCheckPoolBlocks@4))> <NTOSKRNL.EXE:96fa5 (../../ntoskrnl/mm/ARM3/expool.c:2215 (ExFreePoolWithTag@8))> <NTOSKRNL.EXE:9755a (../../ntoskrnl/mm/ARM3/expool.c:2359 (ExFreePool@4))> <NTOSKRNL.EXE:bf8da (../../ntoskrnl/mm/freelist.c:556 (MmDereferencePage@4))> <NTOSKRNL.EXE:bf541 (../../ntoskrnl/mm/balance.c:130 (MmReleasePageMemoryConsumer@8))> <NTOSKRNL.EXE:473b (../../ntoskrnl/cc/view.c:913 (CcFreeCachePage))> <NTOSKRNL.EXE:c1501 (../../ntoskrnl/mm/marea.c:745 (MmFreeMemoryArea@16))> <NTOSKRNL.EXE:413c (../../ntoskrnl/cc/view.c:962 (CcRosInternalFreeCacheSegment))> <NTOSKRNL.EXE:6f3d (../../ntoskrnl/cc/view.c:1145 (CcRosDeleteFileCache@8))> <NTOSKRNL.EXE:755f (../../ntoskrnl/cc/view.c:1210 (CcRosDereferenceCache@4))> <NTOSKRNL.EXE:cb47c (../../ntoskrnl/mm/section.c:2672 (MmpDeleteSection@4))> <NTOSKRNL.EXE:da087 (../../ntoskrnl/ob/oblife.c:211 (ObpDeleteObject@8))> <NTOSKRNL.EXE:da11b (../../ntoskrnl/ob/oblife.c:238 (ObpReapObject@4))> <NTOSKRNL.EXE:41e42 (../../ntoskrnl/ex/work.c:162 (ExpWorkerThreadEntryPoint@4))> <NTOSKRNL.EXE:f2ca9 (../../ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:103c27 (../../ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f2c4f (../../ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>--- Press q to abort, any other key to continue --- <f88b3db8> <NTOSKRNL.EXE:85cc0 (../../ntoskrnl/ke/queue.c:401 (KeRemoveQueue@12))> <NTOSKRNL.EXE:41df0 (../../ntoskrnl/ex/work.c:145 (ExpWorkerThreadEntryPoint@4))> <NTOSKRNL.EXE:f2ca9 (../../ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:103c27 (../../ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f2c4f (../../ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <f88b7db8> <NTOSKRNL.EXE:85cc0 (../../ntoskrnl/ke/queue.c:401 (KeRemoveQueue@12))> <NTOSKRNL.EXE:41df0 (../../ntoskrnl/ex/work.c:145 (ExpWorkerThreadEntryPoint@4))> <NTOSKRNL.EXE:f2ca9 (../../ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:103c27 (../../ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f2c4f (../../ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <f88bbdb8> <NTOSKRNL.EXE:85cc0 (../../ntoskrnl/ke/queue.c:401 (KeRemoveQueue@12))> <NTOSKRNL.EXE:41df0 (../../ntoskrnl/ex/work.c:145 (ExpWorkerThreadEntryPoint@4))> <NTOSKRNL.EXE:f2ca9 (../../ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:103c27 (../../ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f2c4f (../../ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <f889bdb8> <NTOSKRNL.EXE:85cc0 (../../ntoskrnl/ke/queue.c:401 (KeRemoveQueue@12))> <NTOSKRNL.EXE:41df0 (../../ntoskrnl/ex/work.c:145 (ExpWorkerThreadEntryPoint@4))>--- Press q to abort, any other key to continue --- <NTOSKRNL.EXE:f2ca9 (../../ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:103c27 (../../ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f2c4f (../../ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <415c6d6d> Couldn't access memory at 0x5C6C6E76! kdb:> On Thu, Jun 7, 2012, at 06:23 PM, buildbot(a)reactos.org wrote: > 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/5866 > > 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: 56702 > Blamelist: ekohl > > BUILD FAILED: exception test > > sincerely, > -The Buildbot > -- With best regards Caemyr

12 years, 10 months

Debug log problems

by Aleksey Bragin

Hello, it's time for my periodical rant about debug log mess again. The example below is made using latest VirtualBox 3. Suggestions and questions: 1. usbohci - it's left on intentionally to better aid debugging? Allright, however I think these lines (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbohci/hardware.cpp:1199) Waiting 0 milliseconds for port power up (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbohci/hardware.cpp:1145) Enabling status change repeated 8 times is a little bit too much. Same about libusb listing statuses of all ports. Which goes on yet another time with EHCI controller. 2. What are these lines? Repeated 14 times (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a 3. What happened to the floppy driver? (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:1579) '\Driver\FLOPPY' initialization failed, status (0xc000000e) (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:61) Deleting driver object '\Driver\FLOPPY' (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:87) HACK: Not unloading the driver image due to critical bugs! (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:1961) IopInitializeDriver() failed (Status c000000e) (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:935) Leaking driver: floppy.sys Fix it? Don't enable it in trunk builds if it's buggy and not fixed? 4. These lines repeated 20 times. (/srv/buildbot_cmake/full_cmake/build/dll/ntdll/ldr/ldrapi.c:811) NtCreateSection() failed (Status 0xc0000022). Why creating section in LdrpVerifyImageMatchesChecksum() failes now? 5. Win32 stage. (/srv/buildbot_cmake/full_cmake/build/win32ss/user/ntuser/winsta.c:208) err: Invalid window station handle (/srv/buildbot_cmake/full_cmake/build/win32ss/user/ntuser/ntuser.c:161) err: Enter NtUserInitialize(0, 00000000, 00000000) (/srv/buildbot_cmake/full_cmake/build/win32ss/user/ntuser/display.c:79) err: InitDisplayDriver (\Device\Video0, \Registry\Machine\System\CurrentControlSet\Hardware Profiles\Current\System\CurrentControlSet\Services\VBE\Device0); What happens here? It's a normal bootup, everyone should see this. Why is invalid window station handle being passed, why do we need NtUserInitialize to produce ERR debug print, along with InitDisplayDriver. Are those errors? If not, then why the hell are they being printed? If yes, then I don't see any info about actual errors. 6. (/srv/buildbot_cmake/full_cmake/build/win32ss/user/ntuser/window.c:2416) err: DestroyWindow AOW AOW? ORLY? 7. MASSIVE portcls spam. I won't even count lines. (/srv/buildbot_cmake/full_cmake/build/drivers/wdm/audio/backpln/portcls/undoc.cpp:281) Calling Node 16 MajorTarget B01EF750 MinorTarget 00000000 PropertySet {45ffaaa0-6e1b-11d0-bcf2-444553540000} PropertyId 4 PropertyFlags 10000200 InstanceSize 0 ValueSize 40 Handler FB24E58A PropertyRequest FF55B5F8 PropertyItemFlags 203 PropertyItemId 4 A few pages of that stuff. Is it really useful for everyone, including automated testing systems? 8. A work queue deadlock. Not a good thing at all (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/ex/work.c:351) EX: Work Queue Deadlock detected: 1 (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/ex/work.c:353) Dynamic threads queued 2 9. ??? All that resulted from my desire to just compare logs attached to the bug report. New log is totally unreadable, I had to spend time figuring out where actually that Live Essentials app was started, what problems it shows, etc. Best regards, Aleksey.

12 years, 10 months

ReactOS fundraising campaign

by Javier Agustìn Fernàndez Arroyo

Hello, I can see donations have slowed down too much.... so, reaching 30,000 € goal seems ... quite impossible at the short-term... So, i wanted to ask... what about hiring devs for months? i know its a short period of time, but i feel ReactOS needs it ( and them, also, speaking about devs) asap :)

12 years, 10 months

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Debug: build failed

by Pierre Schweitzer

Hi, it appears that one of our servers has decided to definitely give up today. A temporary solution has been deployed to ensure ISOs are still stored properly. But, as a side effect, for the moment: - doxygen is not reachable any longer; - cppcheck run is not reachable any longer; - ISOs are not reachable any longer. We're working to get this back as quick as possible. Sorry for the inconvenience. With my best regards, Le samedi 02 juin 2012 à 04:04 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Debug/builds/876 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 56689 > Blamelist: jimtabor > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

12 years, 10 months

Monthly meeting - May 2012

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 31st of May, 19:00 UTC. The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in the channel #meeting. Note that the IRC service will only be started shortly before the meeting. Your participation passwords will be emailed to you shortly before the meeting starts. If someone still is not getting passwords sent before a meeting - please email Colin or Pierre before the meeting started to get one. In order to save time, let's choose who is going to be the minute taker on the upcoming meeting. As usual, volunteers are welcome. An agenda for the meeting is being worked on now and will be posted later. Please email me your suggestions before the meeting so that the resulting agenda could be compiled beforehand. With the best regards, Aleksey Bragin.

12 years, 10 months

saeid hoveizi

by saeid

hi. I'm a software engineering student last semester. My final project is translation of an open source o/s to Persian( farsi ). i see reactos and download its source code and Introduce the project to svn buti cant build it. please help me or send some useful tutorials.

12 years, 11 months

[ros-diffs] [jimtabor] 56655: - Add RegisterClassNameW to ComCtl32.

by James Tabor

Forgot to add this to the next line, patch is based on Nikolay Sivov patch, http://www.winehq.org/pipermail/wine-patches/2009-December/082963.html .

12 years, 11 months

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Debug: build failed

by Pierre Schweitzer

This was due to a short outage on our side. Problem fixed and build re-queued. Sorry for the inconvenience. Le mercredi 23 mai 2012 à 20:25 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Debug/builds/838 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 56652 > Blamelist: jimtabor > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

12 years, 11 months

Core developer

by none ofyourbussines

What does it take to be a core developer? Oh and MS-DOS® support can be very good and windows has ms-dos® support too!

12 years, 11 months

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Release: build failed

by Pierre Schweitzer

Hi, we are currently experiencing a downtime on our storage network. We are actively working to get this back as soon as possible. As a side effect, SVN is currently in read-only to prevent any further build to be lost. We are sorry for the inconvenience. With my best regards, On Tue, 2012-05-15 at 12:51 +0000, buildbot(a)reactos.org wrote: > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Release while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/73 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1B > > Build Reason: The Periodic scheduler named 'release' triggered this build > Build Source Stamp: HEAD > Blamelist: > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

12 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev