Ros-dev

ros-dev@reactos.org

5788 discussions

by James Tabor

Hi, I was testing with drivers.exe from the W2K DDK. It worked once before about a month ago. Now it crashes the system w/o any display at all. WinObj.exe works fine. Revision: 19187 Node Kind: directory Schedule: normal Last Changed Author: hbirr Last Changed Rev: 19187 Last Changed Date: 2005-11-12 23:45:32 +0000 (Sat, 12 Nov 2005) Properties Last Updated: 2005-10-01 16:19:41 +0000 (Sat, 01 Oct 2005) (subsys/win32k/objects/gdiobj.c:585) Attempted to free global gdi handle 0x13080 1fb, caller needs to get ownership first!!! lib/rtl/unicode.c:916: Pagable code called at IRQL > APC_LEVEL (2) KeBugCheck at ntoskrnl/rtl/libsupp.c:139 (ntoskrnl/mm/mm.c:275) Page fault at high IRQL was 2, address c5b62 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. Technical information: *** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000) Frames: <ntoskrnl.exe:2585 (ntoskrnl/ke/bug.c:479 (KeBugCheckEx))> <ntoskrnl.exe:25bd (ntoskrnl/ke/bug.c:500 (KeBugCheck))> <ntoskrnl.exe:8d20d (ntoskrnl/rtl/libsupp.c:139 (CHECK_PAGED_CODE_RTL))> <ntoskrnl.exe:b9bda (lib/rtl/unicode.c:918 (RtlUnicodeStringToAnsiString))> <ntoskrnl.exe:554cd (ntoskrnl/ldr/loader.c:435 (LdrpQueryModuleInformation))> <ntoskrnl.exe:27f6a (ntoskrnl/ex/sysinfo.c:803 (QSISystemModuleInformation))> <ntoskrnl.exe:28e5d (ntoskrnl/ex/sysinfo.c:1558 (NtQuerySystemInformation))> <ntoskrnl.exe:9c57c ({standard input}:373 (KiSystemService))> <drivers.EXE:146f> Entered debugger on embedded INT3 at 0x0008:0x800b2376. kdb:> bt Eip: <ntoskrnl.exe:b2377 ({standard input}:28 (DbgBreakPointWithStatus))> Frames: <ntoskrnl.exe:2585 (ntoskrnl/ke/bug.c:479 (KeBugCheckEx))> <ntoskrnl.exe:25bd (ntoskrnl/ke/bug.c:500 (KeBugCheck))> <ntoskrnl.exe:8d20d (ntoskrnl/rtl/libsupp.c:139 (CHECK_PAGED_CODE_RTL))> <ntoskrnl.exe:b9bda (lib/rtl/unicode.c:918 (RtlUnicodeStringToAnsiString))> <ntoskrnl.exe:554cd (ntoskrnl/ldr/loader.c:435 (LdrpQueryModuleInformation))> <ntoskrnl.exe:27f6a (ntoskrnl/ex/sysinfo.c:803 (QSISystemModuleInformation))> <ntoskrnl.exe:28e5d (ntoskrnl/ex/sysinfo.c:1558 (NtQuerySystemInformation))> <ntoskrnl.exe:9c57c ({standard input}:373 (KiSystemService))> <drivers.EXE:146f> <drivers.EXE:170f> <kernel32.dll:31635 (lib/kernel32/process/create.c:68 (BaseProcessStartup))> <00000000> kdb:>

19 years

Re: [ros-diffs] [gvg] 20273: /me loves Raymond

by Hartmut Birr

gvg(a)svn.reactos.com wrote: > /me loves Raymond > Modified: trunk/reactos/lib/kernel32/process/create.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/lib/kernel32/process/create.c* > --- trunk/reactos/lib/kernel32/process/create.c 2005-12-19 15:51:57 UTC (rev 20272) > +++ trunk/reactos/lib/kernel32/process/create.c 2005-12-19 17:58:17 UTC (rev 20273) > @@ -668,6 +668,11 @@ > SIZE_T EnvSize = 0; > BOOL Ret = FALSE; > > > + /* FIXME should process > + * HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options > + * key (see http://blogs.msdn.com/oldnewthing/archive/2005/12/19/505449.aspx) > + */ > + > > DPRINT("CreateProcessW: lpApplicationName: %S lpCommandLine: %S" > " lpEnvironment: %p lpCurrentDirectory: %S dwCreationFlags: %lx\n", > lpApplicationName, lpCommandLine, lpEnvironment, lpCurrentDirectory, > Parts of this key are already processed in LoadImageFileExecutionOptions (ntdll\ldr\startup.c). - Hartmut

19 years

Re: [ros-dev] Sysinternals's process explorer

by James Tabor

Alex Buell wrote: > Has anyone tried this on ReactOS? It looks all messed up! > Mean Procexp.exe, yes it works okay with revision 20266. James

19 years

Breakage In Ros

by James Tabor

Hi all, Sometime last night testing build ros, the system locked up. Revision: 20266 Did someone make changes to the handle system a week ago or so? I have family over and I can not keep up with my testing. Thanks, James (./ntoskrnl/ex/sysinfo.c:1098) PID: 0, KernelTime: 61894 PFFree: 50 PFUsed: 0 MC_CACHE 14297, MC_USER 2483, MC_PPOOL 8493, MC_NPPOOL 10812, MmStats.NrFreePage s 217828 (KERNEL32:./lib/kernel32/mem/global.c:412) Memory Load: 14% (MSVCRT:lib/crt/io/open.c:100) not valid fd 0, g_fdend 5, fdinfo 7802f2e0, bucke t 7802f2e0, fdflags 0 (MSVCRT:lib/crt/io/open.c:702) _setmode: inval fd (0) (./ntoskrnl/ex/sysinfo.c:1098) PID: 0, KernelTime: 61894 PFFree: 50 PFUsed: 0 MC_CACHE 14321, MC_USER 2475, MC_PPOOL 8493, MC_NPPOOL 10805, MmStats.NrFreePage s 217819 (KERNEL32:./lib/kernel32/mem/global.c:412) Memory Load: 14% (./ntoskrnl/ex/sysinfo.c:1098) PID: 0, KernelTime: 61894 PFFree: 50 PFUsed: 0 MC_CACHE 14321, MC_USER 2475, MC_PPOOL 8495, MC_NPPOOL 10807, MmStats.NrFreePage s 217815 (KERNEL32:./lib/kernel32/mem/global.c:412) Memory Load: 14% (MSVCRT:lib/crt/io/open.c:100) not valid fd 0, g_fdend 5,Entered debugger on las t-chance exception number 14 (Page Fault) Memory at 0xcccccd60 could not be read: Page not p fdinfo 7802f2e0, bucket 7802f 2e0, fdflags 0 (MSVCRT:lresent. kdb:> bt Eip: <ntoskrnl.exe:78855 (./ntoskrnl/ob/handle.c:0 ())> Frames: <ntoskrnl.exe:78d4c (./ntoskrnl/ob/handle.c:254 (ObpDeleteHandle))> <ntoskrnl.exe:7a1c1 (./ntoskrnl/ob/handle.c:1110 (NtClose))> <ntoskrnl.exe:9ab7c (ntoskrnl/ke/i386/syscall.S:372 (KiSystemService))> <csrss.exe:19af> <csrss.exe:248c> <00000000> kdb:> ib/crtKeBugCheckWithTf at ntoskrnl/ke/i386/exp.c:1242 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The problem seems to be caused by the following file: ntoskrnl.exe Technical information: *** STOP: 0x0000001E (0xc0000005,0x80078855,0x00000000,0xcccccd60) *** ntoskrnl.exe - Address 0x80078855 base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:80078855 <ntoskrnl.exe:78855 (./ntoskrnl/ob/handle.c:0 ()) > cr2 cccccd60 cr3 3cb61000 Proc: 8133b5b8 Pid: 7c <csrss.exe> Thrd: 81d8a538 Tid: 1f0 DS 23 ES 23 FS 30 GS 0 EAX: cccccccc EBX: 8007a111 ECX: 81c92a5c EDX: 81d8a538 EBP: 9ef22cc8 ESI: 0308fe80 ESP: 9ef22c3c EDI: 9ef22d64 EFLAGS: 00010286 kESP 9ef22c3c kernel stack base 9ef20000 Frames: <ntoskrnl.exe:78d4c (./ntoskrnl/ob/handle.c:254 (ObpDeleteHandle))> <ntoskrnl.exe:7a1c1 (./ntoskrnl/ob/handle.c:1110 (NtClose))> <ntoskrnl.exe:9ab7c (ntoskrnl/ke/i386/syscall.S:372 (KiSystemService))> <csrss.exe:19af> Entered debugger on embedded INT3 at 0x0008:0x800b0826. kdb:> bt Eip: <ntoskrnl.exe:b0827 (lib/rtl/i386/debug_asm.S:28 (DbgBreakPointWithStatus))> Frames: <ntoskrnl.exe:9804a (ntoskrnl/ke/i386/exp.c:1237 (KiDispatchException))> <ntoskrnl.exe:96b4f (ntoskrnl/ke/i386/exp.c:194 (KiKernelTrapHandler))> <ntoskrnl.exe:af854 (ntoskrnl/mm/i386/pfault.c:128 (KiPageFaultHandler))> <ntoskrnl.exe:9b261 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))> <ntoskrnl.exe:78855 (./ntoskrnl/ob/handle.c:0 ())> <ntoskrnl.exe:78d4c (./ntoskrnl/ob/handle.c:254 (ObpDeleteHandle))> <ntoskrnl.exe:7a1c1 (./ntoskrnl/ob/handle.c:1110 (NtClose))> <ntoskrnl.exe:9ab7c (ntoskrnl/ke/i386/syscall.S:372 (KiSystemService))> <csrss.exe:19af> <csrss.exe:248c> <00000000> kdb:>

19 years

RE: [ros-dev] RE: 0.2.9 RC2 is Out!

by Murphy, Ged (Bolton)

Ge van Geldorp wrote: > Reminder to devs: with the release of 0.2.9-RC2 we're now in > code freeze for > the branch. During code freeze, the only allowed commits are > bugfixes to > release-blocking bugs. These fixes are generally discussed on > the mailing > list prior to committing a fix. > > GvG I'm not sure if I'm missing something here, but these rules seem to contradict themselves. According to the rules : We don't move from Feature Freeze to Code Freeze until, and I quote "the testing coordinator indicates that all blocker bugs in the release branch have been fixed" I interpret this as, we move to Code Freeze, when and only when all blockers have been fixed. We then dictate that "During code freeze, the only allowed commits are bugfixes to release-blocking bugs" If all blockers must be fixed before we move to Code Freeze, and we can only commit bug fixes to free up blockers during Feature Freeze, what is the actual point in having a Code Freeze as we will never have any blockers to fix. I hope that reads ok. Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

19 years

RE: 0.2.9 RC2 is Out!

by Ge van Geldorp

> From: Brandon Turner > > I just released 0.2.9 to sf.net. A lot of bug fixes since > RC1 so get out there and check it out. File any bugs in in > bugzilla or give us any feedback on the ml. Reminder to devs: with the release of 0.2.9-RC2 we're now in code freeze for the branch. During code freeze, the only allowed commits are bugfixes to release-blocking bugs. These fixes are generally discussed on the mailing list prior to committing a fix. GvG

19 years

RC2 networking not working

by Brandon Turner

Hey all, I was about to publish all the files for 0.2.9 RC2 when i releazied that my network is not working in qemu. It worked a few days ago(friday?). But it isnt working for me now. Is anyone else having this problem? www.brandonturner.org/rc2.PNG Brandon

19 years

[ros-svn] [sgasiorek] 20238: "MSVCRT memcpy behaves like memmove for overlapping moves"

by WaxDragon

This breaks mingw32-make from the RosBE 0.1 WD -- <Russell> argh <Russell> iterator shenanigans :/

19 years

Re: [ros-bugs] [Bug 1149] Calculator bug

by Jerry

I think I got it fixed. Hear's the diff: Index: subsys/system/calc/winecalc.c =================================================================== --- subsys/system/calc/winecalc.c (revision 20239) +++ subsys/system/calc/winecalc.c (working copy) @@ -755,32 +755,34 @@ { int i; int w = LOWORD(wParam); + int Base; + calcfloat r; + + r = calc_atof(calc.buffer, calc.numBase); if (w == ID_CALC_NS_HEX) { - if (calc.numBase == NBASE_HEX) - return 0; - else - calc.numBase = NBASE_HEX; + Base = NBASE_HEX; } else if (w == ID_CALC_NS_DEC) { - if (calc.numBase == NBASE_DECIMAL) - return 0; - else - calc.numBase = NBASE_DECIMAL; + Base = NBASE_DECIMAL; + } else if (w == ID_CALC_NS_OCT) { - if (calc.numBase == NBASE_OCTAL) - return 0; - else - calc.numBase = NBASE_OCTAL; + Base = NBASE_OCTAL; } else if (w == ID_CALC_NS_BIN) { - if (calc.numBase == NBASE_BINARY) + Base = NBASE_BINARY; + } + + if (calc.numBase == Base){ return 0; - else - calc.numBase = NBASE_BINARY; + } else { + calc.numBase = Base; } + + calc_ftoa(&calc, r, calc.buffer); + for (i=0;i<CALC_NS_COUNT;i++) SendMessage(calc.cb[60+i].hBtn, BM_SETCHECK, w == (ID_CALC_NS_HEX + i) ? 1 : 0, 0); @@ -2944,16 +2946,23 @@ switch (calc->numBase) { case NBASE_HEX: - real = calc_atof(calc->buffer, calc->numBase); - _stprintf(calc->display, TEXT("%lx"), (long)real); + //real = calc_atof(calc->buffer, calc->numBase); + //_stprintf(calc->display, TEXT("%lx"), (long)real); + //_stprintf(calc->display, TEXT("%lX"), calc->buffer); + _stprintf(calc->display, TEXT("%s"), calc->buffer); break; case NBASE_OCTAL: - _stprintf(calc->display, TEXT("%lo"), (long)calc->buffer); + //real = calc_atof(calc->buffer, calc->numBase); + //_stprintf(calc->display, TEXT("%lo"), (long)real); + //_stprintf(calc->display, TEXT("%lo"), (long)calc->buffer); + _stprintf(calc->display, TEXT("%s"), calc->buffer); break; case NBASE_BINARY: - _stprintf(calc->display, TEXT("%lx"), (long)calc->buffer); + + //_stprintf(calc->display, TEXT("%lx"), (long)calc->buffer); + _stprintf(calc->display, TEXT("%s"), calc->buffer); break; case NBASE_DECIMAL: @@ -3229,8 +3238,15 @@ case NBASE_OCTAL: _stprintf(buf, TEXT("%lo"), (long)r); break; - case NBASE_BINARY: // 911 - need routine here - + case NBASE_BINARY: // 911 - need routine here + { + int x; + for(x=0; x < sizeof(calcfloat); x++){ + if (( (long)r & (1<<( (sizeof(calcfloat)-1) -x ))) == 1<<( (sizeof(calcfloat)-1) -x ) ) buf[x] = '1'; else buf[x] = '0'; + + }; + buf[sizeof(calcfloat)]='\0'; + } break; default: break; /* End of Diff */ Tell me if it works or not, please. Thanks. ReactOS.Bugzilla(a)reactos.org wrote: >http://www.reactos.org/bugzilla/show_bug.cgi?id=1149 > > > > > >------- Additional Comments From crashfourit(a)gmail.com 2005-12-18 05:27 CET ------- >No, I hadd the same problem in WinXP. I'm in the process of fixing it. > > >

19 years, 1 month

Patch for review: exception handling

by Ge van Geldorp

The program below (when compiled with MSVC6, multithreaded DLL runtime) only prints "in first handler" on ReactOS and then gets into an endless exception loop: int main(int argc, char *argv[]) { __try { RaiseException(0x55aa, 0, 0, NULL); } __except(EXCEPTION_EXECUTE_HANDLER) { printf("in first handler\n"); } __try { RaiseException(0xaacc, 0, 0, NULL); } __except(EXCEPTION_EXECUTE_HANDLER) { printf("in second handler\n"); } return 0; } I believe the reason is that our RtlUnwind removes the target exception frame too, which it shouldn't do. The following patch seems to solve the issue: Index: lib/rtl/i386/exception.c =================================================================== --- lib/rtl/i386/exception.c (revision 20225) +++ lib/rtl/i386/exception.c (working copy) @@ -333,7 +333,10 @@ RegistrationFrame2 = RegistrationFrame2->Next; /* Remove this handler */ - RtlpSetExceptionList(OldFrame); + if (RegistrationFrame2 != RegistrationFrame) + { + RtlpSetExceptionList(OldFrame); + } } } but I'm no expert on exception issues. Is this indeed the correct fix? GvG

19 years, 1 month

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