Ros-dev June 2010

ros-dev@reactos.org

18 participants
15 discussions

Re: [ros-dev] [ros-diffs] [tkreuzer] 47561: revert 47559 and 47560 (once again... sigh)

by Ged Murphy

Windows buildbot! :) -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of tkreuzer(a)svn.reactos.org Sent: 04 June 2010 01:50 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [tkreuzer] 47561: revert 47559 and 47560 (once again... sigh) Author: tkreuzer Date: Fri Jun 4 02:49:33 2010 New Revision: 47561 URL: http://svn.reactos.org/svn/reactos?rev=47561&view=rev Log: revert 47559 and 47560 (once again... sigh)

14 years, 3 months

Communication Problems re 47514 & co.

by Ros Arm

Hello, First I was asked if a certain developer could talk to me regarding ARM3. I said yes, never heard back, and then saw commits done to pfnlist.c. While interesting and useful code, some communication would've been nice in order to talk about the goals, since much of that code is in flux (I feel bad when someone improves a function that I will later remove, as two of the improved functions are only temporary -- the changes to the other functions will remain, obviously). Normally, this would not have been a problem, if not for the strange formatting and the fact this code was now broken and causing a boot regression. I showed up in the #reactos-dev channel and instructed developers on how to fix the problem: remove the entire function and use MiInsertPageInFreeList instead, or fix MiInitializePagingLists to perform its work at DISPATCH_LEVEL instead, by acquiring the PFN lock as it should do. None of this was done, instead "janderwald", in 47514, "Fixed" the ASSERT by saying "Any IRQL lower than DISPATCH_LEVEL" is okay. Janderwald, whoever you are, do you even understand this code? Are you even a kernel-mode developer? Does it make to you that the code would need to assert for low IRQL? The whole point is to validate that the PFN lock is being held. Even if you are not a kernel-mode dev, isn't it clear that all the other assertions are also checking for DISPATCH_LEVEL+? And even if that's not clear, I had written down the solution in the #reactos-dev channel, expecting that probably not many people would figure it out. So I guess some lessons to learn for this project: 1) If you modify someone's code, make sure you test your changes (and preferably don't mess up the formatting) so their code is not now blamed for a boot regression. 2) If someone tells you how to fix their code after it's been messed up, apply the fix. 3) If you choose to roll your own fix, write something useful instead of breaking the function (logic-wise) even more. Again, I'm afraid the problem is most of you are students and don't have work ethics of real employees -- this seems to be the root of many problems this project has had since the last 2 years I've been watching and working on the ARM port. Next steps: - Janderwald: remove your ASSERT hack. Either 1) Remove the ASSERT (stop checking for an invariant that doesn't happen) or 2) Fix the caller (so the invariant holds) - Arthur: changes are appreciated, but let's talk more so you don't end up improving dead code. Carry on! -r

14 years, 3 months

Some proposals for roadmap

by Javier Agustìn Fernàndez Arroyo

hello, i have thinking about an easy way to show people the ReactOS roadmap, and there came to my mind two projects where i have submitted some bug reports before joining ReactOS. They use the "milestone" field in their bug reports for the roadmaps, and its a quite clean way to show it, IMO Here are the links Is there any way to do something similar using Bugzilla? (none of these 2 projects use this Bug Management System) http://www.kdenlive.org/mantis/roadmap_page.php http://developer.pidgin.im/roadmap

14 years, 3 months

Testbots fail to boot ReactOS since 47510

by Olaf Siejka

Since arty's commit in rev 47510, one of his asserts is being triggered in bot qemu and vbox. This practically lock down both testbots as they cannot cont it. I have two requests: - Could you all refrain from commiting until this problem is resolved? - If this issue is not to be fixed soon enough, can this particular assert be commented out for the time being? Debug log below: WARNING: HalStopProfileInterrupt at hal\halx86\generic\profil.c:24 is UNIMPLEMENTED! Assertion 'KeGetCurrentIrql() == DISPATCH_LEVEL' failed at ARMÂł::PFNLIST line 61 Entered debugger on embedded INT3 at 0x0008:0x808e9b7e. kdb:> bt Eip: <808e9b7f (DbgBreakPoint)> Frames: <8089840f (ARM┬│::PFNLIST:61 (MiInsertInListTail@8))> <808a26cd (ntoskrnl/mm/freelist.c:499 (MmInitializePageList@0))> <8089088b (ARM┬│::INIT:X86:521 (MiInitMachineDependent@4))> <80896a61 (ARM┬│::INIT:1846 (MmArmInitSystem@8))> <808a51f7 (ntoskrnl/mm/mminit.c:388 (MmInitSystem@8))> <8084404b (ntoskrnl/ex/init.c:1008 (ExpInitializeExecutive@8))> <8080450b (ntoskrnl/ke/i386/kiinit.c:564 (KiInitializeKernel@24))> <8080467e (ntoskrnl/include//internal/arch/../i386/ke.h:235 (KiSystemStartupBootStack@0))> <0000000e> Entered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0x0007767C could not be read: Page not present. *** Fatal System Error: 0x0000001e (0xC0000005,0x80877985,0x80967DC0,0x00000000) Entered debugger on embedded INT3 at 0x0008:0x808e9b84.

14 years, 3 months

Re: [ros-dev] [ros-diffs] [janderwald] 47509: [NPFS] - Add more buffer checks - Clear DO_DEVICE_INITIALIZING flag

by Ged Murphy

janderwald(a)svn.reactos.org wrote: > + DeviceObject->Flags &= ~DO_DEVICE_INITIALIZING; This is done by the IO manager for any device objects created in DriverEntry If it's not then we have a bug, but I'm fairly sure it does otherwise we wouldn't be able to open devices from umode :) Ged.

14 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev June 2010