Ros-dev

ros-dev@reactos.org

5788 discussions

Re: [ros-svn] [ion] 16728: - Don't try to get the length of a possibly empty string. This fixes many menu applications (such as WinRAR). However I'm now getting a bug due to a double-free. It seems a GDI Object is being freed twice. Can anyone check this out please?

by Alex Ionescu

ion(a)svn.reactos.com wrote: > - Don't try to get the length of a possibly empty string. This fixes many menu applications (such as WinRAR). However I'm now getting a bug due to a double-free. It seems a GDI Object is being freed twice. Can anyone check this out please? > > > With the combination of this patch + Hartmut's patch + DBG = 0 build (and/or disabling RZ detection), Winrar runs fine again. However, pressing OK in the dialog bug causes a crash in RtlFreeUnicodeString->RtlpFreeMemory->ExFreePool. It seems the buffer is invalid. So it looks like two things have to be fixed for Winrar and other apps to work fine (Windows Commander does work now): 1) Stop the GDI Object from being freed twice. This will fix the first bugcheck and allow Winrar to work in DBG = 1 with RZ enabled. Disabling RZ is only a hack and shouldn't be used a solution. The stack trace ships the double-free routine pretty well, but I'm not well versed in win32k to fix this. 2) Find out why we are RtlFreeUnicodestring-ing what seems to be an invalid pointer. I think if we can fix these two issues we'll have many more apps working again! I've tested Winrar 3.50 b7, btw. Best regards, Alex Ionescu

19 years, 5 months

Re: [ros-diffs] [ion] 16804: - Include ctype.h by default.

by Hartmut Birr

ion(a)svn.reactos.com wrote: >- Include ctype.h by default. > >Modified: trunk/reactos/w32api/include/winnt.h > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/w32api/include/winnt.h* > >--- trunk/reactos/w32api/include/winnt.h 2005-07-27 16:34:14 UTC (rev 16803) >+++ trunk/reactos/w32api/include/winnt.h 2005-07-27 16:55:40 UTC (rev 16804) >@@ -34,6 +34,7 @@ > > extern "C" { > #endif > > > >+#include <ctype.h> > > > #include <winerror.h> > > #ifndef RC_INVOKED > > Hi, this changing is wrong (and some other with ctype.h). You can't include ctype.h from mingw for optimized builds (DBG = 0), because ctype.h from mingw needs to import msvcrt.dll. - Hartmut

19 years, 5 months

Blockers...

by Alex Ionescu

Hi, Here is a current update on the 0.2.7 blockers...if you can help, please DO! BUG: - Green icon in run dialog REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to BUILD. CAUSE: Incorrect icon was added to resource file. FIXED: Yes. Fix needs to be merged into 0.2.7 branch. ------------------- BUG: - Common Dialog Control Broken for File/Save. REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to 15669. CAUSE: Building shell32 as ANSI causes this problem. Building it as UNICODE however breaks the My computer dialog. Shell32 should be built as Unicode, and the My computer dialog should appear when double-clicked. So this bug needs to be fixed. ---------------------- BUG: - If you use the arrow keys in the explorer start menu to expand an entry, you cannot use them anymore to go up and down. No further information has been researched yet. Martin, explorer is your baby, and I'm sure is an easy fix...it doesnt' happen with the right-click context menu on the desktop, so maybe this is localized to some bug in your start menu code? --------------------- BUG: - If you right-click on the desktop to show the context menu, then right-click again, then left-click (or other similar combinations), your next right-click is not registered anymore. No further information is available, although I belive hpoussin said the problem is above win32k. I haven't heard from tinus in a long time, but i8042prt might be where this problem resides. ------------------- BUG: - Several applications have regressed due to "memory corruption" and a bugcheck related to NtGdiRealizePallette. More information is on the Bugzilla DB, but it's down atm. I have heard reports that the error always happened before, but wasn't seen because red zone pool protection was disabled. In any case, it breaks a large number of apps. -------------------- BUG: - AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe others). REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression. Best Regards, Alex Ionescu

19 years, 5 months

Re: [ros-svn] [gdalsnes] 16793: my 1st

by Alex Ionescu

gdalsnes(a)svn.reactos.com wrote: >my 1st > > >Added files: >branches/hardons1stbranch/ > >Updated files: >branches/hardons1stbranch/kapi.h >branches/hardons1stbranch/ntuser.h > >Deleted files: >branches/hardons1stbranch/debug.h >branches/hardons1stbranch/debug1.h > > > Hi, I thought our pre-established branching rules recommend using an actual meaningful branch name? Not a generic user branch, but a feature branch. Best regards, Alex Ionescu

19 years, 5 months

RE: [ros-svn] [gdalsnes] 16793: my 1st

by Casper Hornstrup

Can't you rename it to something that reflects its purpose? Casper > -----Original Message----- > From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of > gdalsnes(a)svn.reactos.com > Sent: 27. juli 2005 13:07 > To: ros-svn(a)reactos.com > Subject: [ros-svn] [gdalsnes] 16793: my 1st > > my 1st > > > Added files: > branches/hardons1stbranch/ > > Updated files: > branches/hardons1stbranch/kapi.h > branches/hardons1stbranch/ntuser.h > > Deleted files: > branches/hardons1stbranch/debug.h > branches/hardons1stbranch/debug1.h > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-svn

19 years, 5 months

Re: [ros-svn] [ion] 16727: - Message Queue Fix, resolves a number of application regressions (Total Commander works again, for example). Patch by Hartmut Birr. To be commited into 0.2.7 after more testing.

by Hartmut Birr

ion(a)svn.reactos.com wrote: > - Message Queue Fix, resolves a number of application regressions (Total Commander works again, for example). Patch by Hartmut Birr. To be commited into 0.2.7 after more testing. > > >Updated files: >trunk/reactos/subsys/win32k/ntuser/window.c > > > Hi, this fix wasn't for commiting, because it doesn't solve the real problem. The destroying of the message queues is intitiated by calling Win32kThreadCallback which calls MsqDestroyMessageQueue. After this call, it shouldn't exist anymore a window for this thread. - Hartmut

19 years, 5 months

Re: [ros-svn] [hbirr] 16758: Lock the handle table if we trying to get a pointer from a handle.

by Thomas Weidenmueller

hbirr(a)svn.reactos.com wrote: > Lock the handle table if we trying to get a pointer from a handle. These changes are incorrect. Please revert them. Actually, a handle lookup requires _no_ locks at all. If you don't believe me, read up Windows Internals (4th Edition). The algorithms to allocate subtables are implemented in such a way that it is impossible to page fault on a lookup. However, it is not allowed to do a lookup in a table unless attached to the process that owns it (except it is a global handle table). Best Regards, Thomas

19 years, 5 months

Mozilla Embedded locks in ROS r16740

by reactos

Hello all devs, I am running Mozilla-Embedded (same as BartPE) because I can not get the Mozilla Controll to work, usually this is alright, but since some weeks ago Moz-Embedded locks the computer after the shell says "You're embedded man..." and before the mainwindow starts. It usually took a long time for the mainwindow to start, but it used to work, and I think it takes aproximately the same time for the mouse (and the rest of the system) to lock in r16740. I do not get any error-messages, someone with debugging skills has to look at this. Mozilla embedded can be found here: http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6a/mozilla… Yours sincerely, Jaix Bly

19 years, 5 months

Re: [ros-diffs] [hbirr] 16714: - Removed R_EXTRA_STACK because R_EXTRA_STACK and R_STACK must have the same size.

by Royce Mitchell III

hbirr(a)svn.reactos.com wrote: >- Initialized an allocated block completely before release the lock. > >@@ -719,9 +725,9 @@ > > > { > if ( (NewBlock = RQueRemove ( &pool->Que[que][align] )) ) > { > > >- R_RELEASE_MUTEX(pool); > > > RiUsedInit ( NewBlock, Tag ); > RiUsedInitRedZone ( NewBlock, NumberOfBytes ); > > >+ R_RELEASE_MUTEX(pool); > > > return RHdrToBody(NewBlock); > } > queBytes = 16 << que; >@@ -865,11 +871,10 @@ > > > NewBlock = (PR_USED)BestBlock; > RiUsedInit ( NewBlock, Tag ); > > > >- R_RELEASE_MUTEX(pool); >- > > > /* RtlZeroMemory(RHdrToBody(NewBlock), NumberOfBytes);*/ > > RiUsedInitRedZone ( NewBlock, NumberOfBytes ); > > >+ R_RELEASE_MUTEX(pool); > > > > return RHdrToBody(NewBlock); > } > > Hartmut, If you don't mind, I'm curious how this was causing a problem, the stuff that was being initialized outside of the lock shouldn't (in my feeble mind) have been "visible" upon reentry until this block is freed again. Thanks, Royce

19 years, 5 months

win32k message queue problem

by Hartmut Birr

Hi, it seems there exist a problem with the message queues. If a process is terminated (killed) from outside, the thread message queue is deleted before the last window is deleted. If there is a message (key or mouse) for this window, the window does access the already freed message queue. This will crash the system. Possible it is related to the paged pool memory corruption bug. I've a (dirty) fix for this problem. - Hartmut Index: subsys/win32k/ntuser/window.c =================================================================== --- subsys/win32k/ntuser/window.c (Revision 16707) +++ subsys/win32k/ntuser/window.c (Arbeitskopie) @@ -1577,6 +1577,7 @@ IntSetMenu(WindowObject, hMenu, &MenuChanged); } WindowObject->MessageQueue = PsGetWin32Thread()->MessageQueue; + IntReferenceMessageQueue(WindowObject->MessageQueue); WindowObject->Parent = (ParentWindow ? ParentWindow->Self : NULL); if((OwnerWindow = IntGetWindowObject(OwnerWindowHandle))) { @@ -2180,7 +2181,7 @@ if (Window->MessageQueue->CaptureWindow == Window->Self) Window->MessageQueue->CaptureWindow = NULL; IntUnLockMessageQueue(Window->MessageQueue); - + IntDereferenceMessageQueue(Window->MessageQueue); /* Call hooks */ #if 0 /* FIXME */ if (HOOK_CallHooks(WH_CBT, HCBT_DESTROYWND, (WPARAM) hwnd, 0, TRUE))

19 years, 5 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