Ros-dev

ros-dev@reactos.org

1 participants
5793 discussions

HEAD Regressions
by Alex Ionescu 05 May '05

05 May '05

1) Assertion gets hit on: Assertion PdoNameInfo->Name.Length failed at io/deviface.c:606 Entered debugger on embedded INT3 at 0x0008:0x80005813. 2) Cmd.exe outputs garbage. 3) DHCP crashes during boot. Best regards, Alex Ionescu

7 26

Installation doesn't work with ReactOS.iso and CVS HEAD
by Mark Junker 05 May '05

05 May '05

Hi, while trying to install RectOS, I get the following error messages: (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Control\Class\{36FC9E60-C465-11CF-8056-444553540000}"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Control\Class"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Hardware Profiles\0000"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\KeyboardLayouts\00000406"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\NLS\CodePage"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Services\3c90x"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Enum\PCI\VEN_1022&DEV_2000&SUBSYS_20001022&REV_10\0000"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Enum\PCI\VEN_1022&DEV_2000&SUBSYS_20001022&REV_10"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Enum\PCI"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\ACPI\PNP0501\1"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\ACPI\PNP0501"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Parameters\Device0\Devices"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Parameters\Device0"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Parameters\Device0"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Ne20001\Parameters\Tcpip"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Ne20001\Parameters"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Root\Ne2000\0000"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\Root\Ne2000"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\PCI\0000"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\VEN_8086&DEV_7112&SUBSYS_197615AD&REV_00\0000"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\VEN_2955&DEV_6E61&SUBSYS_6E612955&REV_11\0000"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\PCNet1\Parameters\Tcpip"!) (cm/ntfunc.c:251) NtCreateKey() doesn't create trees! (found '\' in remaining path: "\PCNet1\Parameters"!) After removing the cd and restarting the computer, I get the following error: Plex86/Bochs VGABios 0.5a 07 MÃ¤r 2005 This VGA/VBE Bios is released under the GNU LGPL Please visit : . http://bochs.sourceforge.net . http://www.nongnu.org/vgabios Bochs VBE Display Adapter enabled Bochs BIOS, 1 cpu, $Revision: 1.130 $ $Date: 2005/02/13 08:47:30 $ ata0 master: Generic 1234 ATA-2 Hard-Disk (999 MBytes) ata1 master: Generic 1234 ATAPI-4 CD-Rom/DVD-Rom freeldr.sys not found Press any key to restart Press any key to restart Any idea what goes wrong? Regards, Mark

1 0

Re: [ros-svn] [hbirr] 14988: - Guard the copying to the IOSB.
by Alex Ionescu 05 May '05

05 May '05

hbirr(a)svn.reactos.com wrote: >- Guard the copying to the IOSB. >- Do the main processing on success or if previous STATUS_PENDING was returned. > Do not use some of the IRP and FO flags at this point. > > Ok, I was going to complain about this, but I realize that it must be used since defintely some parts of ROS don't work properly with those flags set. >- Set all results before signaling the events. >- Signal the FO event previous the user event. >- Made the code a little bit shorter. > > > I like your changes and have no complaints, except that the signaling semantics of the File/User events should be different in the failure case (my "else" path). You've completely removed that path and thus changed the logic. Best regards, Alex Ionescu

1 0

about rules.mak, a small bug fixed
by LiGen 05 May '05

05 May '05

When I compile reactos, I find a problem, my make report: string: [DEPENDS] i386/.wcsrchr.d /bin/sh.exe: ....toolsdepends.exe: command not found make[1]: *** [i386/.wcsrchr.d] Error 127 make: *** [string] Error 2 I find the problem is that sh.exe ignored ��\��. The command line is : @gcc -Wall -Werror -D_DISABLE_TIDENTS -D__USE_W32API -fno-strict-aliasing -O6 - I. -I../../include -I../../w32api/include -pipe -march=i486 -D_M_IX86 -Os -Wno-s trict-aliasing -ftracer -momit-leaf-frame-pointer -mpreferred-stack-boundary=2 - funit-at-a-time -fweb -g -M i386/wcsrchr.s | ..\..\tools\depends.exe i386 i386/. wcsrchr.d And ��..\..\tools\depends.exe�� was changed into ��....tools\depends.exe�� by sh.exe My msys is MSYS-1.0.10 So I made a patch on rules.mak , and the problem solved . F:\SVNReactos\reactos>svn diff rules.mak Index: rules.mak =================================================================== --- rules.mak （修订版 14957�? +++ rules.mak （工作拷贝） @@ -122,7 +122,7 @@ export NASM_CMD = $(Q)nasmw export DOSCLI = yes export FLOPPY_DIR = A: -export SEP := \$(EMPTY_VAR) +export SEP := /$(EMPTY_VAR) export PIPE := -pipe endif

2 1

Re: [ros-svn] [hbirr] 14964: Do always set the UserIosb of an irp in IoSecondStageCompletion.
by Alex Ionescu 04 May '05

04 May '05

hbirr(a)svn.reactos.com wrote: >Do always set the UserIosb of an irp in IoSecondStageCompletion. > > > >Updated files: >trunk/reactos/ntoskrnl/io/irp.c > > This is incorrect. 1) The IOSB should not always be set. Create a driver and fail an operation that you send to yourself by an IRP. Make that IRP not SYNCH_API, or better yet, make sure you don't have a File Object. You will notice that the Status Block is not touched. 2) The IOSB is not checked if it exists, it should ALWAYS be there. IRPs without a IOSB are invalid. To verify this, set the IOSB of your IRP to 0 and run Windows with a Debugger. You will see that it will break in many places, because Windows has simply placed SEH to make sure that the write is valid. So the correct thing to do is wrap the write in SEH, which protects both against invalid pointers and zero ones, but that still doesn't mean they are"valid" and should be checked that way. Best regards, Alex Ionescu

3 5

Both CMD Consoles Go Puff!
by James Tabor 04 May '05

04 May '05

Hi All! Wow! Ros on ros build and I walk away come back and both consoles are gone. Thank god for taskmgr! It shows both cmds', ctm, and three make.exe, not running but still in memory. Build 14598 (KERNEL32:mem/global.c:412) Memory Load: 23 (KERNEL32:mem/global.c:412) Memory Load: 23 (MSVCRT:io/open.c:103) not valid fd 0, g_fdend 5, fdinfo 7802d2f0, bucket 7802d2 f0, fdflags 0 (MSVCRT:io/open.c:700) _setmode: inval fd (0) (NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000) C:\ReactOS\System32\gdi 32.dll (NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 850000) C:\ReactOS\system32\gdi 32.dll (NTDLL:rtl/critical.c:446) Deadlock: 8517f8 Unhandled exception Address: 7c90a05c C:\ReactOS\system32\ntdll.dll CS:EIP 1b:7c90a3d2 DS 23 ES 23 FS 3b GS 23 EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 EBP: 019afdd8 ESI: 00000000 ESP: 019afde0 EDI: 00000000 EFLAGS: 00000212 Frames: 7c900000+a05c C:\ReactOS\system32\ntdll.dll 5ffb0000+8381 C:\ReactOS\system32\win32csr.dll 5ffb0000+8eac C:\ReactOS\system32\win32csr.dll 220000+12a8f C:\ReactOS\system32\user32.dll 220000+12ced C:\ReactOS\system32\user32.dll 5ffb0000+91c4 C:\ReactOS\system32\win32csr.dll 7c800000+26554 C:\ReactOS\system32\kernel32.dll (NTDLL:rtl/critical.c:446) Deadlock: 8517f8 (ke/catch.c:191) Unhandled UserMode exception, terminating thread Explorer is running btw, James

2 4

ping
by Hartmut Birr 04 May '05

04 May '05

3 2

RE: [ros-dev] gcc problem or not
by Waldo Alvarez Cañizares 04 May '05

04 May '05

Hi: I doubt this could be a bug. A lot of code would break with it. Maybe it does violates the short circuit in the small number of cases where that can be done. As in this case, it doesn't matters. Regards Waldo ________________________________ From: ros-dev-bounces(a)reactos.com on behalf of Hartmut Birr Sent: Tue 5/3/2005 2:43 PM To: ReactOS Development List Subject: [ros-dev] gcc problem or not Hi, I've looked on a map file from an optimized build. I found the following code: /* * If the directory containing the file to open doesn't exist then * fail immediately */ if (Status == STATUS_OBJECT_PATH_NOT_FOUND || 12015: 83 c4 0c add $0xc,%esp 12018: 89 c3 mov %eax,%ebx 1201a: 3d 3a 00 00 c0 cmp $0xc000003a,%eax 1201f: 0f 94 c2 sete %dl 12022: 3d 0d 00 00 c0 cmp $0xc000000d,%eax 12027: 0f 94 c0 sete %al 1202a: 09 d0 or %edx,%eax 1202c: a8 01 test $0x1,%al 1202e: 0f 85 42 01 00 00 jne 12176 <_VfatCreateFile+0x2e9> 12034: 81 fb 56 00 00 c0 cmp $0xc0000056,%ebx 1203a: 0f 84 36 01 00 00 je 12176 <_VfatCreateFile+0x2e9> Status == STATUS_INVALID_PARAMETER || Status == STATUS_DELETE_PENDING) { if (ParentFcb) { vfatReleaseFCB (DeviceExt, ParentFcb); } return(Status); } I was always the opinion that the examination of a test condition stops if the result can not change again. A test condition like this: if (pointer == NULL || pointer->member == 0) should never access pointer->member if pointer is zero. Compared with the code above, it is possible that gcc build the result from the right side of the OR statement. This may hit a page fault. Is this a bug in gcc? - Hartmut _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev

1 0

gcc problem or not
by Hartmut Birr 03 May '05

03 May '05

Hi, I've looked on a map file from an optimized build. I found the following code: /* * If the directory containing the file to open doesn't exist then * fail immediately */ if (Status == STATUS_OBJECT_PATH_NOT_FOUND || 12015: 83 c4 0c add $0xc,%esp 12018: 89 c3 mov %eax,%ebx 1201a: 3d 3a 00 00 c0 cmp $0xc000003a,%eax 1201f: 0f 94 c2 sete %dl 12022: 3d 0d 00 00 c0 cmp $0xc000000d,%eax 12027: 0f 94 c0 sete %al 1202a: 09 d0 or %edx,%eax 1202c: a8 01 test $0x1,%al 1202e: 0f 85 42 01 00 00 jne 12176 <_VfatCreateFile+0x2e9> 12034: 81 fb 56 00 00 c0 cmp $0xc0000056,%ebx 1203a: 0f 84 36 01 00 00 je 12176 <_VfatCreateFile+0x2e9> Status == STATUS_INVALID_PARAMETER || Status == STATUS_DELETE_PENDING) { if (ParentFcb) { vfatReleaseFCB (DeviceExt, ParentFcb); } return(Status); } I was always the opinion that the examination of a test condition stops if the result can not change again. A test condition like this: if (pointer == NULL || pointer->member == 0) should never access pointer->member if pointer is zero. Compared with the code above, it is possible that gcc build the result from the right side of the OR statement. This may hit a page fault. Is this a bug in gcc? - Hartmut

7 9

RE: [ros-svn] [ion] 14799: KD System Rewrite:
by Ge van Geldorp 03 May '05

03 May '05

> From: ion(a)svn.reactos.com > > KD System Rewrite: This utterly broke the GDB stub, to the point that I can't even use DbgPrint anymore to try and figure out what's wrong. May I suggest you go and read http://www.joelonsoftware.com/articles/fog0000000069.html first, revert this patch (so I can get on with my work), and then, if you still feel this overwhelming urge to rewrite, test all the functionality you're replacing (you obviously didn't even consider a "/DEBUGPORT=GDB" and boot test necessary) before recommiting. If I sound a little bit pissed-off, that's because it's exactly how I feel. This is not the first time I've been bitten by a rewrite. Back in January I spent a lot of time improving symbol handling and profiling, only to see you remove the profiling code a few weeks later, for a "new and improved" rewrite. Only problem is, the "new and improved" profiling system doesn't produce any output and is therefore useless. You said you would fix that in a weeks time, but now, months later, still nothing. I'll be damned if I'm going to let the same happen to the GDB stub, which I use on a daily basis. We all break stuff sometimes (God knows I do) and I can live with that. I can even live with rewrites when they're necessary for binary compatibility (after all, that's what this project is all about) but I'm highly suspicious of rewrites because of "well, uhmm, I think my way is cleaner". Gé van Geldorp.

2 3

Jump to page:

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