Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-dev] [ros-diffs] [akhaldi] 56731: [CMAKE/MIDL] * Alter the way we handle the dlldata generation with midl. This works around the warnings we get about multiple rules to generate proxy.dlldata.c. * Brought to yo by ...
by Timo Kreuzer 16 Jun '12

16 Jun '12

Did you test dependency checking? Am 14.06.2012 13:06, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Thu Jun 14 11:06:23 2012 > New Revision: 56731 > > URL:http://svn.reactos.org/svn/reactos?rev=56731&view=rev > Log: > [CMAKE/MIDL] > * Alter the way we handle the dlldata generation with midl. This works around the warnings we get about multiple rules to generate proxy.dlldata.c. > * Brought to yo by Peter Kummel. > > Modified: > trunk/reactos/cmake/midl-support.cmake > > Modified: trunk/reactos/cmake/midl-support.cmake > URL:http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/midl-support.cma… > ============================================================================== > --- trunk/reactos/cmake/midl-support.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/midl-support.cmake [iso-8859-1] Thu Jun 14 11:06:23 2012 > @@ -38,16 +38,17 @@ > get_includes(_includes) > get_defines(_defines) > set(_chain_dependency "") > + set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/proxy.dlldata.c PROPERTIES GENERATED TRUE) > foreach(_idl_file ${ARGN}) > get_filename_component(_name_we ${_idl_file} NAME_WE) > add_custom_command( > - OUTPUT ${_name_we}_p.c ${_name_we}_p.h proxy.dlldata.c > + OUTPUT ${_name_we}_p.c ${_name_we}_p.h > COMMAND midl ${_includes} ${_defines} ${IDL_FLAGS} /client none /server none /proxy ${_name_we}_p.c /h ${_name_we}_p.h /dlldata proxy.dlldata.c ${CMAKE_CURRENT_SOURCE_DIR}/${_idl_file} > DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_idl_file} ${_chain_dependency}) > list(APPEND _chain_dependency ${CMAKE_CURRENT_BINARY_DIR}/${_name_we}_p.c) > list(APPEND _chain_dependency ${CMAKE_CURRENT_BINARY_DIR}/${_name_we}_p.h) > + set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/proxy.dlldata.c PROPERTIES OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_idl_file}) > endforeach() > - set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/proxy.dlldata.c PROPERTIES GENERATED TRUE) > endfunction() > > function(add_rpc_files _type) > > >

1 0

Re: [ros-dev] buildbot exception in ReactOS on Windows_AMD64_1 VBox-Test
by caemyr＠myopera.com 07 Jun '12

07 Jun '12

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

1 0

Debug log problems
by Aleksey Bragin 07 Jun '12

07 Jun '12

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.

8 11

ReactOS fundraising campaign
by Javier Agustìn Fernàndez Arroyo 06 Jun '12

06 Jun '12

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 :)

4 5

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Debug: build failed
by Pierre Schweitzer 04 Jun '12

04 Jun '12

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

1 2

Monthly meeting - May 2012
by Aleksey Bragin 31 May '12

31 May '12

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.

6 9

saeid hoveizi
by saeid 25 May '12

25 May '12

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.

1 0

[ros-diffs] [jimtabor] 56655: - Add RegisterClassNameW to ComCtl32.
by James Tabor 24 May '12

24 May '12

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 .

1 0

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Debug: build failed
by Pierre Schweitzer 23 May '12

23 May '12

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

1 0

Core developer
by none ofyourbussines 16 May '12

16 May '12

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!

9 23

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