Hi all, Had a lockup. CVS from < 24 hours ago. Running in cmd only no gui.
(KERNEL32:mem/global.c:412) Memory Load: 15 (ex/sysinfo.c:961) SystemFullMemoryInformation (ex/sysinfo.c:973) PID: 1, KernelTime: 8027895 PcrKTime: 8111975 PcrIdleTime: 80 14109 TickCount: 8269998 PFFree: 65536 PFUsed: 0
TickCount is good!
MC_CACHE 29840, MC_USER 2208, MC_PPOOL 777, MC_NPPOOL 6726, MmStats.NrFreePages 214383 (KERNEL32:mem/global.c:412) Memory Load: 15 (conio.c:1029) Console_Api Ctrl-C (KERNEL32:misc/console.c:2966) GenerateConsoleCtrlEvent(0x0, 0x42c4) UNIMPLEMENT ED!
PS dump;
P PID PPID KTime UTime NAME t TID KTime UTime State WaitResson w PID Hwnd WndStile TID WndName P 1 0 22:50:45 0:00:00 ProcName: SYSTEM t 2 0:00:32 0:00:00 Unknown Executive t 3 22:48:26 0:00:00 Ready Executive t 4 0:00:00 0:00:00 Unknown WrQueue t 5 0:00:00 0:00:00 Unknown WrQueue t 6 0:00:00 0:00:00 Unknown WrQueue t 7 0:00:00 0:00:00 Unknown WrQueue t 8 0:00:00 0:00:00 Unknown WrQueue t 9 0:00:00 0:00:00 Unknown WrQueue t 10 0:00:00 0:00:00 Unknown WrQueue t 11 0:00:00 0:00:00 Unknown WrQueue t 12 0:00:00 0:00:00 Unknown WrQueue t 13 0:00:00 0:00:00 Unknown WrQueue t 14 0:00:00 0:00:00 Unknown WrQueue t 15 0:00:00 0:00:00 Unknown WrQueue t 16 0:00:00 0:00:00 Unknown WrQueue t 17 0:00:00 0:00:00 Unknown WrQueue t 18 0:00:00 0:00:00 Unknown WrQueue t 19 0:01:58 0:00:00 Unknown Executive t 20 0:00:00 0:00:00 Unknown Executive t 21 0:00:00 0:00:00 Unknown Executive t 22 0:00:03 0:00:00 Unknown Executive t 24 0:00:00 0:00:00 Unknown Executive t 29 0:00:00 0:00:00 Unknown Executive t 30 0:00:00 0:00:00 Unknown Executive t 31 0:00:00 0:00:00 Unknown Executive P 2 1 0:00:00 0:00:00 ProcName: smss.exe t 25 0:00:00 0:00:00 Unknown UserReq t 26 0:00:00 0:00:00 Unknown UserReq t 27 0:00:00 0:00:00 Unknown UserReq P 4 2 0:00:54 0:00:02 ProcName: csrss.exe t 33 0:00:09 0:00:00 Unknown UserReq t 34 0:00:00 0:00:00 Unknown UserReq t 35 0:00:00 0:00:00 Unknown Executive t 36 0:00:00 0:00:00 Unknown UserReq t 38 0:00:00 0:00:00 Unknown UserReq t 39 0:00:00 0:00:00 Unknown Executive w 4 4 00000000 39 t 40 0:00:00 0:00:00 Unknown Executive w 4 8 86000000 40 t 41 0:00:00 0:00:00 Unknown Executive w 4 c 86000000 41 t 43 0:00:00 0:00:00 Unknown UserReq t 46 0:00:00 0:00:00 Unknown UserReq t 49 0:00:00 0:00:00 Unknown UserReq t 46453 0:00:00 0:00:00 Unknown UserReq t 46467 0:00:00 0:00:00 Unknown UserReq P 5 2 0:00:00 0:00:00 ProcName: winlogon.exe t 37 0:00:00 0:00:00 Unknown UserReq w 5 10 84000000 37 SAS P 6 5 0:00:00 0:00:00 ProcName: services.exe t 42 0:00:00 0:00:00 Unknown UserReq t 44 0:00:00 0:00:00 Unknown UserReq P 7 6 0:00:00 0:00:00 ProcName: eventlog.exe t 45 0:00:00 0:00:00 Unknown UserReq t 47 0:00:00 0:00:00 Unknown UserReq P 8 5 0:00:00 0:00:00 ProcName: cmd.exe t 48 0:00:00 0:00:00 Unknown UserReq
Look here!
P 23169 17092 0:00:00 0:00:00 ProcName: make.exe P 23208 23169 0:00:00 0:00:00 ProcName: gcc.exe P 23210 23208 0:00:00 0:00:00 ProcName: as.exe t 46452 0:00:00 0:00:00 Unknown UserReq
Ctrl-break did not kill these.
FYI, James
�Reactos�s Bootcd� Just wondering why those files are not include because many apps depends on them and they are made?
olepro32.dll oledlg.dll odbc32.dll
Is it necessary to apply files in patches when you made a whole dynamic link file? My mind lay on inetcfg.dll and other files witch only are ugly stubs in Reactos CVS.
Is there a tool to do the diff-patch job anyone can recommend?
Who are able to get CVS Write Access and how?
Got Dependx86 running on my own Patched Version of Reactos with allot of patch fixing
So you can se the depends that files uses but wondering
Every application using the open dialog from e.g. �Wordpad.exe� crash/halt the application and make Reactos unstable it�s the same with depends.exe.
Cant really find the mistake in comdlg32.dll comctrl32.dll just hoped that any one know about that maybe a patch or some.
Reactos identify itself as some old Windows Version but if any apps should be able to run it should be at least Windows 2000 know about
BuildLab CSDVersion CurrentBuild CurrentBuildNumber CurrentVersion
Tried to change it to be Windows 2000 but still the apps identify it as some old NT version and that really irritates me, made a lot of patch and new dll�s but can really test their use and function be cures of that so hoped anyone know about where files check the Windows Version
My last question is
I start and application but if the application gets missing exports lets say NTDLL.RtlAlloc The Reactos Gets very unstable I know windows do some other things when a exports missing it shows and dialog saying either NTDLL.DLL is missing or the Function NTDLL.RtlAlloc is missing and then terminate the application..
If any have a solution about where I should solve the problem or got some patch to do it I would be very happyJ
__________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Thomas Larsen Sent: 8. december 2004 09:54 To: ReactOS Development List Subject: [ros-dev] Reactos Dev Help
Reactos4s Bootcd Just wondering why those files are not include because many apps depends on them and they are made?
olepro32.dll oledlg.dll odbc32.dll
Submit a patch that will do this, then they will be included in the next release.
Is it necessary to apply files in patches when you made a whole dynamic link file?
Please elaborate on that
My mind lay on inetcfg.dll and other files witch only are ugly stubs in Reactos CVS.
What is ugly about them?
Is there a tool to do the diff-patch job anyone can recommend?
GNU diff and GNU patch
Who are able to get CVS Write Access and how?
When you have made a series of non-trivial patches, you may apply for CVS access.
Reactos identify itself as some old Windows Version but if any apps should be able to run it should be at least Windows 2000 know about
There is a reason the applications wants a newer OS. They need some APIs only available on newer OS versions. To support APIs of multiple OS versions concurrently, ReactOS needs an Application Compatibility System like Windows has.
My last question is
I start and application but if the application gets missing exports lets say NTDLL.RtlAlloc The Reactos Gets very unstable I know windows do some other things when a exports missing it shows and dialog saying either NTDLL.DLL is missing or the Function NTDLL.RtlAlloc is missing and then terminate the application..
If any have a solution about where I should solve the problem or got some patch to do it I would be very happyJ
Use an older version of GNU binutils to build ReactOS.
Casper
Thomas Larsen wrote:
“Reactos´s Bootcd” Just wondering why those files are not include because many apps depends on them and they are made?
olepro32.dll oledlg.dll odbc32.dll
I guess it is simply because these DLLs aren't used by ReactOS yet. Otherwise someone would have added them to the list of installable components.
Is it necessary to apply files in patches when you made a whole dynamic link file? My mind lay on inetcfg.dll and other files witch only are ugly stubs in Reactos CVS.
New files don't need to be published as patches. But if you change an existing file send a patch.
Is there a tool to do the diff-patch job anyone can recommend?
The command-line CVS does a good job for creating patches from your local tree. Run 'cvs -z9 diff -u -N -R >patch.diff' from the root of your ReactOS source tree and patch.diff will contain all changes including new files.
For use with local files you can get diffutils and patch from here: http://gnuwin32.sourceforge.net/packages.html
Who are able to get CVS Write Access and how?
You can get CVS write access after you submitted some (read: more than one) useful patches to the developers mailing list. You have to show that you are willing and able to become a contributor to ReactOS. We don't want to give write access to someone who submits only two patches.
Got Dependx86 running on my own Patched Version of Reactos with allot of patch fixing
Please submit your patch to the deleopers mailing list.
So you can se the depends that files uses but wondering
Every application using the open dialog from e.g. “Wordpad.exe” crash/halt the application and make Reactos unstable it’s the same with depends.exe.
Cant really find the mistake in comdlg32.dll comctrl32.dll just hoped that any one know about that maybe a patch or some.
You will have to build a small testcase that does nothing but call the FileOpen dialog in order to find out what's wrong.
Reactos identify itself as some old Windows Version but if any apps should be able to run it should be at least Windows 2000 know about
BuildLab CSDVersion CurrentBuild CurrentBuildNumber CurrentVersion
Tried to change it to be Windows 2000 but still the apps identify it as some old NT version and that really irritates me, made a lot of patch and new dll´s but can really test their use and function be cures of that so hoped anyone know about where files check the Windows Version
There is more than one way to retrieve the current Windows version and all of them need to be fixed.
My last question is
I start and application but if the application gets missing exports lets say NTDLL.RtlAlloc The Reactos Gets very unstable I know windows do some other things when a exports missing it shows and dialog saying either NTDLL.DLL is missing or the Function NTDLL.RtlAlloc is missing and then terminate the application..
The loader, a part of ntdll (see lib/ntdll/ldr), should stop loading the application and report an error. At least it should happen if you start the application from the command-line. If you start an application from explorers 'Run' dialog a message box should report the error. If it doesn't Explorer needs fixing.
Regards, Eric
Hi all,
Starting to get this every once in a while in the debug output;
(heap.c:991) Heap 00840000: block 0072f5cc is not inside heap
Thanks, James
(heap.c:991) Heap 00840000: block 0072f5cc is not inside heap
I've tried to eliminate these few days ago. These messages come from code that is broken and tries to free non-pointers. If you can generate backtrace from the code (eg. put breakpoint at rtl/heap.c:992) and debug it, it would be nice. Even if you can just produce the backtrace and match it with function names and send it to me, it would be great.
One fix that I haven't commited to ROS CVS yet was for the cabinet dll used by MSI installer. If you want to try it, I've sent it to wine-patches.
Regards, Filip
Filip Navara schrieb:
(heap.c:991) Heap 00840000: block 0072f5cc is not inside heap
I've tried to eliminate these few days ago. These messages come from code that is broken and tries to free non-pointers. If you can generate backtrace from the code (eg. put breakpoint at rtl/heap.c:992) and debug it, it would be nice. Even if you can just produce the backtrace and match it with function names and send it to me, it would be great.
One fix that I haven't commited to ROS CVS yet was for the cabinet dll used by MSI installer. If you want to try it, I've sent it to wine-patches.
Regards, Filip
It is possible that the bug is related to msvcrt. The core heap functions are using the heap from msvcrt. The wine heap functions are using the process heap. If a block is allocated with one of the functions and deallocated with one of the other functions, it will also fail with such an error message.
- Hartmut
Hi Hartmut,
--- Hartmut Birr hartmut.birr@gmx.de wrote:
It is possible that the bug is related to msvcrt. The core heap functions are using the heap from msvcrt. The wine heap functions are using the process heap. If a block is allocated with one of the functions and deallocated with one of the other functions, it will also fail with such an error message.
Sorry about the mess in msvcrt. I imported that trying to get the CxxFrameHandler working and did not know what the hell I was doing. I will try to remove as much of the Wine stuff as I can without causing a regression and see if it helps.
Thanks Steven
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
This patch implements double-free detection in paged pool, except that for some reason ReactOS seems to just freeze solid as soon as reaching the desktop when I apply it.
Would someone please look at the patch and possibly try it to see if they get the same results, or if they see anything wrong with it?
Index: ntoskrnl/mm/ppool.c =================================================================== RCS file: /CVS/ReactOS/reactos/ntoskrnl/mm/ppool.c,v retrieving revision 1.33 diff -u -r1.33 ppool.c --- ntoskrnl/mm/ppool.c 20 Nov 2004 21:16:38 -0000 1.33 +++ ntoskrnl/mm/ppool.c 9 Dec 2004 13:49:52 -0000 @@ -22,17 +22,31 @@
#undef assert #define assert(x) if (!(x)) {DbgPrint("Assertion "#x" failed at %s:%d\n", __FILE__,__LINE__); KeBugCheck(0); } -#define ASSERT_SIZE(n) assert ( (n) <= MmPagedPoolSize && (n) >= 0 ) +#define ASSERT_SIZE(n) assert ( (n) <= MmPagedPoolSize && (n) > 0 ) #define ASSERT_PTR(p) assert ( ((size_t)(p)) >= ((size_t)MmPagedPoolBase) && ((size_t)(p)) < ((size_t)((size_t)MmPagedPoolBase+MmPagedPoolSize)) )
// to disable buffer over/under-run detection, set the following macro to 0 +#if !defined(DBG) && !defined(KDBG) +#define MM_PPOOL_REDZONE_BYTES 0 +#else #define MM_PPOOL_REDZONE_BYTES 4 -#define MM_PPOOL_REDZONE_VALUE 0xCD +#define MM_PPOOL_REDZONE_LOVALUE 0x87 +#define MM_PPOOL_REDZONE_HIVALUE 0xA5 +#define MM_PPOOL_FREEMAGIC (ULONG)(('F'<<0) + ('r'<<8) + ('E'<<16) + ('e'<<24)) +#define MM_PPOOL_USEDMAGIC (ULONG)(('u'<<0) + ('S'<<8) + ('e'<<16) + ('D'<<24)) +#define MM_PPOOL_LASTOWNER_ENTRIES 3 +#endif
typedef struct _MM_PPOOL_FREE_BLOCK_HEADER { ULONG Size; +#if MM_PPOOL_REDZONE_BYTES + ULONG FreeMagic; +#endif//MM_PPOOL_REDZONE_BYTES struct _MM_PPOOL_FREE_BLOCK_HEADER* NextFree; +#if MM_PPOOL_REDZONE_BYTES + ULONG LastOwnerStack[MM_PPOOL_LASTOWNER_ENTRIES]; +#endif//MM_PPOOL_REDZONE_BYTES } MM_PPOOL_FREE_BLOCK_HEADER, *PMM_PPOOL_FREE_BLOCK_HEADER;
@@ -40,7 +54,7 @@ { ULONG Size; #if MM_PPOOL_REDZONE_BYTES - + ULONG UsedMagic; ULONG UserSize; // how many bytes the user actually asked for... struct _MM_PPOOL_USED_BLOCK_HEADER* NextUsed; #endif//MM_PPOOL_REDZONE_BYTES @@ -86,6 +100,12 @@ MmPagedPoolFirstFreeBlock->NextFree = NULL;
#if MM_PPOOL_REDZONE_BYTES + MmPagedPoolFirstFreeBlock->FreeMagic = MM_PPOOL_FREEMAGIC; + { + int i; + for ( i = 0; i < MM_PPOOL_LASTOWNER_ENTRIES; i++ ) + MmPagedPoolFirstFreeBlock->LastOwnerStack[i] = 0; + }
MmPagedPoolFirstUsedBlock = NULL; #endif//MM_PPOOL_REDZONE_BYTES @@ -102,6 +122,9 @@ while ( p ) { DPRINT ( " 0x%x: %lu bytes (next 0x%x)\n", p, p->Size, p->NextFree ); +#if MM_PPOOL_REDZONE_BYTES + ASSERT ( p->FreeMagic == MM_PPOOL_FREEMAGIC ); +#endif//MM_PPOOL_REDZONE_BYTES ASSERT_PTR(p); ASSERT_SIZE(p->Size); count++; @@ -114,34 +137,71 @@ #define VerifyPagedPool() #endif
+#if !MM_PPOOL_REDZONE_BYTES +#define MmpRedZoneCheck(pUsed,Addr,file,line) +#else//MM_PPOOL_REDZONE_BYTES +static VOID FASTCALL +MmpRedZoneCheck ( PMM_PPOOL_USED_BLOCK_HEADER pUsed, PUCHAR Addr, const char* file, int line ) +{ + int i; + PUCHAR AddrEnd = Addr + pUsed->UserSize; + BOOL bLow = TRUE; + BOOL bHigh = TRUE; + + ASSERT_PTR(Addr); + if ( pUsed->UsedMagic == MM_PPOOL_FREEMAGIC ) + { + PMM_PPOOL_FREE_BLOCK_HEADER pFree = (PMM_PPOOL_FREE_BLOCK_HEADER)pUsed; + DPRINT1 ( "Double-free detected for Block 0x%x!\n", Addr ); + DbgPrint ( "First Free Stack Frames:" ); + for ( i = 0; i < MM_PPOOL_LASTOWNER_ENTRIES; i++ ) + DbgPrint ( " <%x>", pFree->LastOwnerStack[i] ); + KEBUGCHECK(BAD_POOL_HEADER); + } + if ( pUsed->UsedMagic != MM_PPOOL_USEDMAGIC ) + { + DPRINT1 ( "Bad magic in Block 0x%x!\n", Addr ); + KEBUGCHECK(BAD_POOL_HEADER); + } + ASSERT_SIZE(pUsed->Size); + ASSERT_SIZE(pUsed->UserSize); + ASSERT_PTR(AddrEnd); + Addr -= MM_PPOOL_REDZONE_BYTES; // this is to simplify indexing below... + for ( i = 0; i < MM_PPOOL_REDZONE_BYTES && bLow && bHigh; i++ ) + { + bLow = bLow && ( Addr[i] == MM_PPOOL_REDZONE_LOVALUE ); + bHigh = bHigh && ( AddrEnd[i] == MM_PPOOL_REDZONE_HIVALUE ); + } + if ( !bLow || !bHigh ) + { + const char* violation = "High and Low-side"; + if ( bHigh ) // high is okay, so it was just low failed + violation = "Low-side"; + else if ( bLow ) // low side is okay, so it was just high failed + violation = "High-side"; + DbgPrint("%s(%i): %s redzone violation detected for paged pool address 0x%x\n", + file, line, violation, Addr ); + DbgPrint ( "UsedMagic 0x%x, LoZone ", pUsed->UsedMagic ); + for ( i = 0; i < MM_PPOOL_REDZONE_BYTES; i++ ) + DbgPrint ( "%02x", Addr[i] ); + DbgPrint ( ", HiZone " ); + for ( i = 0; i < MM_PPOOL_REDZONE_BYTES; i++ ) + DbgPrint ( "%02x", AddrEnd[i] ); + DbgPrint ( "\n" ); + KEBUGCHECK(BAD_POOL_HEADER); + } +} +#endif//MM_PPOOL_REDZONE_BYTES + VOID STDCALL MmDbgPagedPoolRedZoneCheck ( const char* file, int line ) { #if MM_PPOOL_REDZONE_BYTES PMM_PPOOL_USED_BLOCK_HEADER pUsed = MmPagedPoolFirstUsedBlock; - int i; - BOOL bLow = TRUE; - BOOL bHigh = TRUE;
while ( pUsed ) { - PUCHAR Addr = (PUCHAR)block_to_address(pUsed); - for ( i = 0; i < MM_PPOOL_REDZONE_BYTES; i++ ) - { - bLow = bLow && ( *(Addr-i-1) == MM_PPOOL_REDZONE_VALUE ); - bHigh = bHigh && ( *(Addr+pUsed->UserSize+i) == MM_PPOOL_REDZONE_VALUE ); - } - if ( !bLow || !bHigh ) - { - const char* violation = "High and Low-side"; - if ( bHigh ) // high is okay, so it was just low failed - violation = "Low-side"; - else if ( bLow ) // low side is okay, so it was just high failed - violation = "High-side"; - DbgPrint("%s(%i): %s redzone violation detected for paged pool address 0x%x\n", - file, line, violation, Addr ); - KEBUGCHECK(0); - } + MmpRedZoneCheck ( pUsed, block_to_address(pUsed), __FILE__, __LINE__ ); pUsed = pUsed->NextUsed; } #endif//MM_PPOOL_REDZONE_BYTES @@ -270,6 +330,9 @@ (PMM_PPOOL_FREE_BLOCK_HEADER)address_to_block(BestAlignedAddr); assert ( BestAlignedAddr > Addr ); NewFreeBlock->Size = (char*)Addr + BestBlock->Size - (char*)BestAlignedAddr; +#if MM_PPOOL_REDZONE_BYTES + NewFreeBlock->FreeMagic = MM_PPOOL_FREEMAGIC; +#endif//MM_PPOOL_REDZONE_BYTES ASSERT_SIZE(NewFreeBlock->Size); BestBlock->Size = (size_t)NewFreeBlock - (size_t)Addr; ASSERT_SIZE(BestBlock->Size); @@ -344,6 +407,9 @@ NextBlock = (PMM_PPOOL_FREE_BLOCK_HEADER)((char*)BestBlock + BlockSize); //DPRINT("."); NextBlock->Size = NewSize; +#if MM_PPOOL_REDZONE_BYTES + NextBlock->FreeMagic = MM_PPOOL_FREEMAGIC; +#endif//MM_PPOOL_REDZONE_BYTES ASSERT_SIZE ( NextBlock->Size ); //DPRINT("."); NextBlock->NextFree = BestBlock->NextFree; @@ -372,6 +438,9 @@ NewBlock = (PMM_PPOOL_USED_BLOCK_HEADER)BestBlock; //DPRINT("."); NewBlock->Size = BlockSize; +#if MM_PPOOL_REDZONE_BYTES + NewBlock->UsedMagic = MM_PPOOL_USEDMAGIC; +#endif//MM_PPOOL_REDZONE_BYTES ASSERT_SIZE ( NewBlock->Size ); //DPRINT(".\n"); } @@ -397,6 +466,9 @@ */ NewBlock = (PMM_PPOOL_USED_BLOCK_HEADER)BestBlock; NewBlock->Size = NewSize; +#if MM_PPOOL_REDZONE_BYTES + NewBlock->UsedMagic = MM_PPOOL_USEDMAGIC; +#endif//MM_PPOOL_REDZONE_BYTES ASSERT_SIZE ( NewBlock->Size ); }
@@ -421,17 +493,9 @@ PUCHAR Addr = (PUCHAR)BlockAddress; //DbgPrint ( "writing buffer-overrun detection bytes" ); memset ( Addr - MM_PPOOL_REDZONE_BYTES, - MM_PPOOL_REDZONE_VALUE, MM_PPOOL_REDZONE_BYTES ); - memset ( Addr + NewBlock->UserSize, MM_PPOOL_REDZONE_VALUE, + MM_PPOOL_REDZONE_LOVALUE, MM_PPOOL_REDZONE_BYTES ); + memset ( Addr + NewBlock->UserSize, MM_PPOOL_REDZONE_HIVALUE, MM_PPOOL_REDZONE_BYTES ); - /*for ( i = 0; i < MM_PPOOL_REDZONE_BYTES; i++ ) - { - //DbgPrint("."); - *(Addr-i-1) = 0xCD; - //DbgPrint("o"); - *(Addr+NewBlock->UserSize+i) = 0xCD; - }*/ - //DbgPrint ( "done!\n" ); }
#endif//MM_PPOOL_REDZONE_BYTES @@ -452,29 +516,7 @@
ASSERT_IRQL(APC_LEVEL);
-#if MM_PPOOL_REDZONE_BYTES - // write out buffer-overrun detection bytes - { - int i; - PUCHAR Addr = (PUCHAR)Block; - //DbgPrint ( "checking buffer-overrun detection bytes..." ); - for ( i = 0; i < MM_PPOOL_REDZONE_BYTES; i++ ) - { - if (*(Addr-i-1) != MM_PPOOL_REDZONE_VALUE) - { - DPRINT1("Attempt to free memory %#08x. Redzone underrun!\n", Block); - } - if (*(Addr+UsedBlock->UserSize+i) != MM_PPOOL_REDZONE_VALUE) - { - DPRINT1("Attempt to free memory %#08x. Redzone overrun!\n", Block); - } - - assert ( *(Addr-i-1) == MM_PPOOL_REDZONE_VALUE ); - assert ( *(Addr+UsedBlock->UserSize+i) == MM_PPOOL_REDZONE_VALUE ); - } - //DbgPrint ( "done!\n" ); - } -#endif//MM_PPOOL_REDZONE_BYTES + MmpRedZoneCheck ( UsedBlock, Block, __FILE__, __LINE__ );
ExAcquireFastMutex(&MmPagedPoolLock);
@@ -503,6 +545,29 @@ * Begin setting up the newly freed block's header. */ FreeBlock->Size = UsedSize; +#if MM_PPOOL_REDZONE_BYTES + FreeBlock->FreeMagic = MM_PPOOL_FREEMAGIC; + { + PULONG Frame; + int i; +#if defined __GNUC__ + __asm__("mov %%ebp, %%ebx" : "=b" (Frame) : ); +#elif defined(_MSC_VER) + __asm mov [Frame], ebp +#endif + Frame = (PULONG)Frame[0]; // step out of ExFreePagedPool + for ( i = 0; i < MM_PPOOL_LASTOWNER_ENTRIES; i++ ) + { + if ( Frame == 0 || (ULONG)Frame == 0xDEADBEEF ) + FreeBlock->LastOwnerStack[i] = 0xDEADBEEF; + else + { + FreeBlock->LastOwnerStack[i] = Frame[1]; + Frame = (PULONG)Frame[0]; + } + } + } +#endif//MM_PPOOL_REDZONE_BYTES ASSERT_SIZE ( FreeBlock->Size );
/* @@ -533,6 +598,7 @@ /* * If the next block is immediately adjacent to the newly freed one then * merge them. + * PLEASE DO NOT WIPE OUT 'MAGIC' OR 'LASTOWNER' DATA FOR MERGED FREE BLOCKS */ if (NextBlock != NULL && ((char*)FreeBlock + FreeBlock->Size) == (char*)NextBlock) @@ -550,6 +616,7 @@ /* * If the previous block is adjacent to the newly freed one then * merge them. + * PLEASE DO NOT WIPE OUT 'MAGIC' OR 'LASTOWNER' DATA FOR MERGED FREE BLOCKS */ if (PreviousBlock != NULL && ((char*)PreviousBlock + PreviousBlock->Size) == (char*)FreeBlock)
issue resolved, if noone objects, I will commit this pagedpool double-free detection patch.
Would anybody object to me changing:
DPRINT(foo)
to
DPRINT((foo))
in the name of msvc6 compilability?
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Royce Mitchell III Sent: 9. december 2004 19:41 To: ReactOS Development List Subject: [ros-dev] DPRINT
Would anybody object to me changing:
DPRINT(foo)to
DPRINT((foo))in the name of msvc6 compilability?
I would. This will give you maintainance hell. Either you need to fix it every time some developer using MinGW use the first version or you will need to constantly remind these developers to use the second version (eg. more work for them).
Casper
Casper Hornstrup wrote:
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Royce Mitchell III Sent: 9. december 2004 19:41 To: ReactOS Development List Subject: [ros-dev] DPRINT
Would anybody object to me changing:
DPRINT(foo)
to
DPRINT((foo))
in the name of msvc6 compilability?
I would. This will give you maintainance hell. Either you need to fix it every time some developer using MinGW use the first version or you will need to constantly remind these developers to use the second version (eg. more work for them).
Casper
Well, first off I could do it in a way that DPRINT(foo) wouldn't compile, so it would remind them automatically
The only other solutions I've come up with are less pretty:
1) DPRINT0(foo) DPRINT1(foo,a) DPRINT2(foo,a,b) etc... a serious problem with this is that DPRINT1 already means something different than DPRINT...
2) #define _C_ , DPRINT(foo _C_ a _C_ b) this is ugly and probably couldn't be protected from uncaring mingwers.
Royce Mitchell III wrote:
Well, first off I could do it in a way that DPRINT(foo) wouldn't compile, so it would remind them automatically
The only other solutions I've come up with are less pretty:
- DPRINT0(foo) DPRINT1(foo,a) DPRINT2(foo,a,b) etc... a serious problem with this is that DPRINT1 already means
something different than DPRINT...
- #define _C_ , DPRINT(foo _C_ a _C_ b) this is ugly and probably couldn't be protected from uncaring
mingwers.
hardon pointed out that we are doing this for MSVC, which is a good enough solution, I guess:
#define DPRINT DbgPrint("(%s:%d) ",__FILE__,__LINE__); DbgPrint
The reason I brought all this up is because last time I started to try to compile for msvc I was running into this problem. I guess somebody fixed it while I was away.
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Royce Mitchell III Sent: 9. december 2004 20:52 To: ReactOS Development List Subject: Re: [ros-dev] DPRINT
Casper Hornstrup wrote:
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of Royce Mitchell III Sent: 9. december 2004 19:41 To: ReactOS Development List Subject: [ros-dev] DPRINT
Would anybody object to me changing:
DPRINT(foo)
to
DPRINT((foo))
in the name of msvc6 compilability?
I would. This will give you maintainance hell. Either you
need to fix
it every time some developer using MinGW use the first
version or you
will need to constantly remind these developers to use the second version (eg. more work for them).
Casper
Well, first off I could do it in a way that DPRINT(foo) wouldn't compile, so it would remind them automatically
The only other solutions I've come up with are less pretty:
- DPRINT0(foo) DPRINT1(foo,a) DPRINT2(foo,a,b) etc... a serious problem with this is that DPRINT1 already
means something different than DPRINT...
- #define _C_ , DPRINT(foo _C_ a _C_ b) this is ugly and probably couldn't be protected from
uncaring mingwers.
I that case, if you can make DPRINT(foo) cause a warning when used improperly, stating how it is supposed to be used, I don't have any objections.
Casper
Hi,
--- Casper Hornstrup chorns@users.sourceforge.net wrote:
I that case, if you can make DPRINT(foo) cause a warning when used improperly, stating how it is supposed to be used, I don't have any objections.
Ditto, If you can fix it to build in MS_VC and throw warnings if someone does a wrong DPRINT it would be very nice.
Thanks Steven
__________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com
Hi, Filip Navara wrote:
(heap.c:991) Heap 00840000: block 0072f5cc is not inside heap
I've tried to eliminate these few days ago. These messages come from code that is broken and tries to free non-pointers. If you can generate backtrace from the code (eg. put breakpoint at rtl/heap.c:992) and debug it, it would be nice. Even if you can just produce the backtrace and match it with function names and send it to me, it would be great.
One fix that I haven't commited to ROS CVS yet was for the cabinet dll used by MSI installer. If you want to try it, I've sent it to wine-patches.
Regards, Filip
I wish I had more time, everything is so busy! Go for it and commit your changes! Thanks, James
James Tabor wrote:
I wish I had more time, everything is so busy! Go for it and commit your changes!
I've commited fixes for all heap errors that I've encountered so far. If you encounter some other one and have a reproducible test case for it, don't hesitate and mail me.
Regards, Filip
Hi, Still getting them, current cvs at this time, (heap.c:1015) Heap 00840000: block 0072f5cc is not inside heap
Not all the time, I will save the log file (woo! big file!) and when I get the time (other that just testing and spending no more than 20 min a day on ros), I will set the break points for the heap.
Sorry I can not do more, James
Filip Navara wrote:
James Tabor wrote:
I wish I had more time, everything is so busy! Go for it and commit your changes!
I've commited fixes for all heap errors that I've encountered so far. If you encounter some other one and have a reproducible test case for it, don't hesitate and mail me.
Regards, Filip
-
Casper Hornstrup -
eric.kohl＠t-online.de -
Filip Navara -
Hartmut Birr -
James Tabor -
Royce Mitchell III -
Steven Edwards -
Thomas Larsen