Hi,
doing a tools/wineinstall on a clean system yields in an X-Error.
Doing:
winedbg rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf
gives:
.. Wine-dbg>bt Backtrace: =>1 0x00abec49 (0x00a6d7f4) 2 0x00656d76 _XcmsSine+0xe6 in x11drv (0x00a6d818) 3 0x00767b5a WIN_DestroyWindow+0xf2(hwnd=0x30026) [/data/install/linux/wine-src/wine/dlls/user/../../windows/win.c:655] in user32 (0x00a6d830) 4 0x007699be DestroyWindow+0x116(hwnd=0x30026) [/data/install/linux/wine-src/wine/dlls/user/../../windows/win.c:1517] in user32 (0x00a6d854) 5 0x00ff6862 COM_ApartmentRelease+0x146(apt=0x77e60090) [/data/install/linux/wine-src/wine/dlls/ole32/compobj.c:338] in ole32 (0x00a6d870) 6 0x00ff6f54 CoUninitialize+0x100 [/data/install/linux/wine-src/wine/dlls/ole32/compobj.c:641] in ole32 (0x00a6d888) 7 0x00934c2f register_filters+0x28f(list=0x946700) [regsvr.c:644] in quartz (0x00a6d8e0) 8 0x009350cb QUARTZ_DllRegisterServer+0x6b [regsvr.c:1078] in quartz (0x00a6d8f0) 9 0x00843686 do_register_dll+0xca(info=0xa6fb80, path=0x77e51400, flags=0x1, timeout=0x3c, args=0x0) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:491] in setupapi (0x00a6d924) 10 0x00843a2a register_dlls_callback+0x1a6(hinf=0x77e15ce0, field=0xa6f9b4, arg=0xa6fb80) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:574] in setupapi (0x00a6f970) 11 0x00843f48 iterate_section_fields+0xe0(hinf=0x77e15ce0, section=0xa6fbe4, key=0x852420, callback=0x843884, arg=0xa6fb80) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:696] in setupapi (0x00a6fb50) 12 0x0084421c SetupInstallFromInfSectionW+0x8c(owner=0x10024, hinf=0x77e15ce0, section=0xa6fbe4, flags=0x3ff, key_root=0x0, src_root=0x0, copy_flags=0x4, callback=0x84a894, context=0x77e8bda8, devinfo=0x0, devinfo_data=0x0) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:851] in setupapi (0x00a6fbac) 13 0x00844625 InstallHinfSectionW+0x101(hwnd=0x10024, handle=0xc30000, cmdline=0x77bd05a8, show=0x1) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:934] in setupapi (0x00a6fe00) 14 0x00c327da main+0x1aa(argc=0x5, argv=0x77de0420) [/data/install/linux/wine-src/wine/programs/rundll32/rundll32.c:291] in rundll32 (0x00a6fe9c) 15 0x00c32163 __wine_exe_main+0x163 in rundll32 (0x00a6ff2c) 16 0x0029d2d7 start_process+0xc3(arg=0x0) [/data/install/linux/wine-src/wine/dlls/kernel/process.c:1046] in kernel32 (0x00a6fff4) 17 0x004ec6a5 __GI_____strtof_l_internal+0x155 in libc.so.6 (0x00000000)
I didn't do a regression test yet, to find the cause, but the error seems to be in COM_ApartmentRelease during the DestroyWindow(apt->win)
I've applied OLE # 45 already.
Will do some more testing tonight.
Cheers,
Paul.
Paul Vriens wrote:
Hi,
doing a tools/wineinstall on a clean system yields in an X-Error.
Doing:
winedbg rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf
gives:
.. Wine-dbg>bt Backtrace: =>1 0x00abec49 (0x00a6d7f4) 2 0x00656d76 _XcmsSine+0xe6 in x11drv (0x00a6d818) 3 0x00767b5a WIN_DestroyWindow+0xf2(hwnd=0x30026) [/data/install/linux/wine-src/wine/dlls/user/../../windows/win.c:655] in user32 (0x00a6d830) 4 0x007699be DestroyWindow+0x116(hwnd=0x30026) [/data/install/linux/wine-src/wine/dlls/user/../../windows/win.c:1517] in user32 (0x00a6d854) 5 0x00ff6862 COM_ApartmentRelease+0x146(apt=0x77e60090) [/data/install/linux/wine-src/wine/dlls/ole32/compobj.c:338] in ole32 (0x00a6d870) 6 0x00ff6f54 CoUninitialize+0x100 [/data/install/linux/wine-src/wine/dlls/ole32/compobj.c:641] in ole32 (0x00a6d888) 7 0x00934c2f register_filters+0x28f(list=0x946700) [regsvr.c:644] in quartz (0x00a6d8e0) 8 0x009350cb QUARTZ_DllRegisterServer+0x6b [regsvr.c:1078] in quartz (0x00a6d8f0) 9 0x00843686 do_register_dll+0xca(info=0xa6fb80, path=0x77e51400, flags=0x1, timeout=0x3c, args=0x0) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:491] in setupapi (0x00a6d924) 10 0x00843a2a register_dlls_callback+0x1a6(hinf=0x77e15ce0, field=0xa6f9b4, arg=0xa6fb80) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:574] in setupapi (0x00a6f970) 11 0x00843f48 iterate_section_fields+0xe0(hinf=0x77e15ce0, section=0xa6fbe4, key=0x852420, callback=0x843884, arg=0xa6fb80) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:696] in setupapi (0x00a6fb50) 12 0x0084421c SetupInstallFromInfSectionW+0x8c(owner=0x10024, hinf=0x77e15ce0, section=0xa6fbe4, flags=0x3ff, key_root=0x0, src_root=0x0, copy_flags=0x4, callback=0x84a894, context=0x77e8bda8, devinfo=0x0, devinfo_data=0x0) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:851] in setupapi (0x00a6fbac) 13 0x00844625 InstallHinfSectionW+0x101(hwnd=0x10024, handle=0xc30000, cmdline=0x77bd05a8, show=0x1) [/data/install/linux/wine-src/wine/dlls/setupapi/install.c:934] in setupapi (0x00a6fe00) 14 0x00c327da main+0x1aa(argc=0x5, argv=0x77de0420) [/data/install/linux/wine-src/wine/programs/rundll32/rundll32.c:291] in rundll32 (0x00a6fe9c) 15 0x00c32163 __wine_exe_main+0x163 in rundll32 (0x00a6ff2c) 16 0x0029d2d7 start_process+0xc3(arg=0x0) [/data/install/linux/wine-src/wine/dlls/kernel/process.c:1046] in kernel32 (0x00a6fff4) 17 0x004ec6a5 __GI_____strtof_l_internal+0x155 in libc.so.6 (0x00000000)
I didn't do a regression test yet, to find the cause, but the error seems to be in COM_ApartmentRelease during the DestroyWindow(apt->win)
This is strange. The window handle should be verified valid, so I don't think we're calling DestroyWindow on an invalid window handle from COM_ApartmentRelease. This isn't my area, so I don't really know what would cause the XError. I presume it is a bug in the window management code.
Rob
"Paul Vriens" paul.vriens@xs4all.nl writes:
doing a tools/wineinstall on a clean system yields in an X-Error.
What's the X error?
On Wed, 2005-01-19 at 16:53, Alexandre Julliard wrote:
"Paul Vriens" paul.vriens@xs4all.nl writes:
doing a tools/wineinstall on a clean system yields in an X-Error.
What's the X error?
The error:
(default is /home/paul/.wine/drive_c) /data/wine-c Configuring Wine for a no-windows install in /data/wine-c... wine: Unhandled exception (thread 0009), starting debugger... X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 12 (X_ConfigureWindow) Resource id in failed request: 0x687b16f8 Serial number of failed request: 153 Current serial number in output stream: 159
and part of a trace:
0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460, oxid 800000009 0009:trace:ole:MARSHAL_Disconnect_Proxies () 0009:trace:win:DestroyWindow (0x30024) 0009:trace:win:SetWindowPos hwnd 0x30024, after (nil), 0,0 (0x0), flags 00000097 0009:trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_NOZORDER SWP_NOACTIVATE SWP_HIDEWINDOW 0009:trace:x11drv:X11DRV_SetWindowPos hwnd 0x30024, after (nil), swp 0,0 0x0 flags 00000097 0009:trace:x11drv:SWP_DoWinPosChanging hwnd 0x30024, after (nil), swp 0,0 0x0 flags 00001897 0009:trace:x11drv:SWP_DoWinPosChanging current (0,0)-(0,0) style 04c00000 new (0,0)-(0,0) 0009:trace:x11drv:X11DRV_set_window_pos win 0x30024 window (0,0)-(0,0) client (0,0)-(0,0) style 04c00000 0009:trace:x11drv:X11DRV_sync_whole_window_position setting win 77e6ec40 pos 0,0,0x0 after 3acfc1e8 changes=c 0009:trace:x11drv:X11DRV_sync_client_window_position setting win e436eb83 pos 0,0,0x0 (was 2011037792,2011584840,-2011037792x-2011584823) after 1 changes=f 0009:trace:x11drv:X11DRV_SetWindowPos status flags = 1807 wine: Unhandled exception (thread 0009), starting debugger... 0009:err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x41075af4
If you want a better trace, let me know.
Paul.
Paul Vriens Paul.Vriens@xs4all.nl writes:
and part of a trace:
0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460, oxid 800000009
Looks like some sort of heap corruption, the apartment pointer is suspiciously similar to the bad contents of the x11drv window structure.
If you want a better trace, let me know.
Yes I'd be interested to see the whole trace.
On Wed, 2005-01-19 at 20:32, Alexandre Julliard wrote:
Paul Vriens Paul.Vriens@xs4all.nl writes:
and part of a trace:
0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460, oxid 800000009
Looks like some sort of heap corruption, the apartment pointer is suspiciously similar to the bad contents of the x11drv window structure.
If you want a better trace, let me know.
Yes I'd be interested to see the whole trace.
All seems to point to patch http://cvs.winehq.org/patch.py?id=15392
I'm not a 100% convinced as I have some trouble with the regression testing. I started with a clean installed Wine upto this patch and I get the XError. If I go one patch back I don't see the problem.
Paul.
On Thu, 2005-01-20 at 11:47, Paul Vriens wrote:
On Wed, 2005-01-19 at 20:32, Alexandre Julliard wrote:
Paul Vriens Paul.Vriens@xs4all.nl writes:
and part of a trace:
0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460, oxid 800000009
Looks like some sort of heap corruption, the apartment pointer is suspiciously similar to the bad contents of the x11drv window structure.
If you want a better trace, let me know.
Yes I'd be interested to see the whole trace.
All seems to point to patch http://cvs.winehq.org/patch.py?id=15392
I'm not a 100% convinced as I have some trouble with the regression testing. I started with a clean installed Wine upto this patch and I get the XError. If I go one patch back I don't see the problem.
Paul.
Ok, I'm convinced that the mentioned patch gives the X Error. But while I was investigating the following happened:
I ran "wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf" from within the tools directory. This gives the X Error.
I did this several times after each other with the same result.
I than ran "WINEDEBUG=+ole wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf" and the error is gone !?!?
The registry is now filled with all the default data.
Any ideas how to proceed ? Is there a timing issue ?
Paul.
Paul Vriens wrote:
On Thu, 2005-01-20 at 11:47, Paul Vriens wrote:
On Wed, 2005-01-19 at 20:32, Alexandre Julliard wrote:
Paul Vriens Paul.Vriens@xs4all.nl writes:
and part of a trace:
0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460, oxid 800000009
Looks like some sort of heap corruption, the apartment pointer is suspiciously similar to the bad contents of the x11drv window structure.
If you want a better trace, let me know.
Yes I'd be interested to see the whole trace.
All seems to point to patch http://cvs.winehq.org/patch.py?id=15392
I'm not a 100% convinced as I have some trouble with the regression testing. I started with a clean installed Wine upto this patch and I get the XError. If I go one patch back I don't see the problem.
Paul.
Ok, I'm convinced that the mentioned patch gives the X Error. But while I was investigating the following happened:
I ran "wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf" from within the tools directory. This gives the X Error.
I did this several times after each other with the same result.
I than ran "WINEDEBUG=+ole wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf" and the error is gone !?!?
The registry is now filled with all the default data.
Any ideas how to proceed ? Is there a timing issue ?
If it's heap corruption then it could well depend on the order of allocations, so it could be timing dependent. I've attached a patch that poisons the apartment structure after when it is freed so that hopefully any use-after-free will become more obvious. Could you apply it and see what the results are? Does the X Error stop? Do we now get warnings about accessing a handle of 0xcccccccc (run with warn+all for this)?
Rob
On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
Paul Vriens wrote:
On Thu, 2005-01-20 at 11:47, Paul Vriens wrote:
On Wed, 2005-01-19 at 20:32, Alexandre Julliard wrote:
Paul Vriens Paul.Vriens@xs4all.nl writes:
and part of a trace:
0009:trace:ole:COM_ApartmentRelease destroying apartment 0x77e64460, oxid 800000009
Looks like some sort of heap corruption, the apartment pointer is suspiciously similar to the bad contents of the x11drv window structure.
If you want a better trace, let me know.
Yes I'd be interested to see the whole trace.
All seems to point to patch http://cvs.winehq.org/patch.py?id=15392
I'm not a 100% convinced as I have some trouble with the regression testing. I started with a clean installed Wine upto this patch and I get the XError. If I go one patch back I don't see the problem.
Paul.
Ok, I'm convinced that the mentioned patch gives the X Error. But while I was investigating the following happened:
I ran "wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf" from within the tools directory. This gives the X Error.
I did this several times after each other with the same result.
I than ran "WINEDEBUG=+ole wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf" and the error is gone !?!?
The registry is now filled with all the default data.
Any ideas how to proceed ? Is there a timing issue ?
If it's heap corruption then it could well depend on the order of allocations, so it could be timing dependent. I've attached a patch that poisons the apartment structure after when it is freed so that hopefully any use-after-free will become more obvious. Could you apply it and see what the results are? Does the X Error stop? Do we now get warnings about accessing a handle of 0xcccccccc (run with warn+all for this)?
Rob
Index: dlls/ole32/compobj.c
RCS file: /home/wine/wine/dlls/ole32/compobj.c,v retrieving revision 1.129 diff -u -p -r1.129 compobj.c --- dlls/ole32/compobj.c 20 Jan 2005 10:35:46 -0000 1.129 +++ dlls/ole32/compobj.c 20 Jan 2005 17:16:37 -0000 @@ -329,6 +329,9 @@ DWORD COM_ApartmentRelease(struct apartm
DeleteCriticalSection(&apt->cs); CloseHandle(apt->thread);
/* fill memory with invalid data to try and make us crash if we reuse* it */memset(apt, 0xcc, sizeof(*apt)); HeapFree(GetProcessHeap(), 0, apt);
Hi Rob,
these are the last lines of the warn+all:
warn:file:wine_nt_to_unix_file_name L"quartz.dll" not found in /home/paul/.wine/dosdevices/z:/data/install/linux/wine-src/wine/tools warn:file:wine_nt_to_unix_file_name L"quartz.dll" not found in /home/paul/.wine/dosdevices/z:/data/install/linux/wine-src/wine/tools warn:file:wine_nt_to_unix_file_name L"quartz.dll" not found in /home/paul/.wine/dosdevices/c:/windows/system warn:file:wine_nt_to_unix_file_name L"quartz.dll" not found in /home/paul/.wine/dosdevices/c:/windows warn:heap:HEAP_ValidateInUseArena Heap 77de0000: invalid in-use arena magic for 77e5b948 warn:heap:HEAP_ValidateInUseArena Heap 77de0000: invalid in-use arena magic for 77e5b948 X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 18 (X_ChangeProperty) Resource id in failed request: 0x77de0060 Serial number of failed request: 107 Current serial number in output stream: 113
there is no message regarding a accessing a handle of 0xcccccccc
Cheers,
Paul.
On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
If it's heap corruption then it could well depend on the order of allocations, so it could be timing dependent. I've attached a patch that poisons the apartment structure after when it is freed so that hopefully any use-after-free will become more obvious. Could you apply it and see what the results are? Does the X Error stop? Do we now get warnings about accessing a handle of 0xcccccccc (run with warn+all for this)?
Rob
see my previous email for the warn+err piece.
I now did a warn+all,+ole trace and checked for warn:heap messages, there are a lot of them. I don't know if they are 'normal' warnings or related to the problem I'm seeing:
trace:ole:COMPOBJ_DLLList_Add trace:ole:WINE_StringFromCLSID 0x57bbc254->{083863F1-70DE-11D0-BD40-00A0C911CE86} trace:ole:WINE_StringFromCLSID 0x57bbbf84->{1B544C20-FD0B-11CE-8C63-00AA0044B51E} trace:ole:WINE_StringFromCLSID 0x57bbc224->{4315D437-5B8C-11D0-BD3B-00A0C911CE86} trace:ole:CoGetClassObject CLSID: {4315d437-5b8c-11d0-bd3b-00a0c911ce86}, IID: {00000001-0000-0000-c000-000000000046} trace:ole:COMPOBJ_DLLList_Add trace:ole:CreateBindCtx (0,0x1036d808) trace:ole:BindCtxImpl_Construct (0x6d940bd0) trace:ole:BindCtxImpl_QueryInterface (0x6d940bd0,0x1036d7b4,0x1036d808) trace:ole:BindCtxImpl_AddRef (0x6d940bd0) trace:ole:__CLSIDFromStringA {083863F1-70DE-11D0-BD40-00A0C911CE86} -> 0x1036d7a8 trace:ole:WINE_StringFromCLSID 0x1036d7a8->{083863F1-70DE-11D0-BD40-00A0C911CE86} trace:ole:BindCtxImpl_Release (0x6d940bd0) trace:ole:BindCtxImpl_ReleaseBoundObjects (0x6d940bd0) trace:ole:BindCtxImpl_Destroy (0x6d940bd0) trace:ole:WINE_StringFromCLSID 0x57bbbf84->{1B544C20-FD0B-11CE-8C63-00AA0044B51E} warn:heap:HEAP_IsRealArena Heap 0x6d8d0000: block 0x690077 is not inside heap
btw. adding the +ole made the X Error go away as before.
Cheers,
Paul.
On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
If it's heap corruption then it could well depend on the order of allocations, so it could be timing dependent. I've attached a patch that poisons the apartment structure after when it is freed so that hopefully any use-after-free will become more obvious. Could you apply it and see what the results are? Does the X Error stop? Do we now get warnings about accessing a handle of 0xcccccccc (run with warn+all for this)?
Rob
I can remember having a conversation with Christian Costa for the same kind of error.
That was after he added some extra filter registration in quartz/regsvr.c. I just played around with the CoInitialize in register_filters. I changed CoInitialize(NULL) into CoInitializeEx(NULL, COINIT_MULTITHREADED) and the error was gone.
When I do the same change now, the X Error is gone as well. Does this give you a clue?
Paul.
On Thu, 20 Jan 2005 19:36:27 +0100, Paul Vriens wrote:
When I do the same change now, the X Error is gone as well. Does this give you a clue?
Could you try this patch please?
--- dlls/ntdll/thread.c (revision 109) +++ dlls/ntdll/thread.c (local) @@ -73,6 +73,7 @@ static TEB *alloc_teb( ULONG *size ) teb->Peb = &peb; teb->StaticUnicodeString.Buffer = teb->StaticUnicodeBuffer; teb->StaticUnicodeString.MaximumLength = sizeof(teb->StaticUnicodeBuffer); + teb->ReservedForOle = NULL; return teb; }
thanks -mike
On Thu, 2005-01-20 at 20:17, Mike Hearn wrote:
On Thu, 20 Jan 2005 19:36:27 +0100, Paul Vriens wrote:
When I do the same change now, the X Error is gone as well. Does this give you a clue?
Could you try this patch please?
--- dlls/ntdll/thread.c (revision 109) +++ dlls/ntdll/thread.c (local) @@ -73,6 +73,7 @@ static TEB *alloc_teb( ULONG *size ) teb->Peb = &peb; teb->StaticUnicodeString.Buffer = teb->StaticUnicodeBuffer; teb->StaticUnicodeString.MaximumLength = sizeof(teb->StaticUnicodeBuffer);
- teb->ReservedForOle = NULL; return teb;
}
thanks -mike
Sorry, didn't help.
I'm going to try Rob's suggestions now.
Paul.
On Thu, 2005-01-20 at 20:32 +0100, Paul Vriens wrote:
Sorry, didn't help.
I'm going to try Rob's suggestions now.
Right, Alexandre just clued me in that anonymous mmaps are always zerod. Nice theory, but no cigar this time. I've been able to reproduce the bug (sometimes) and am narrowing it down now. Let's see who gets there first! ;)
On Thu, 2005-01-20 at 20:32 +0100, Paul Vriens wrote:
Sorry, didn't help.
I'm going to try Rob's suggestions now.
This patch fixes it for me.
Mike Hearn mh@codeweavers.com Fix heap corruption in quartz server registration, add some whitespace, break out of loop if out of memory
--- dlls/quartz/regsvr.c (revision 109) +++ dlls/quartz/regsvr.c (local) @@ -577,7 +577,6 @@ static HRESULT register_filters(struct r IFilterMapper2* pFM2 = NULL;
CoInitialize(NULL); - hr = CoCreateInstance(&CLSID_FilterMapper2, NULL, CLSCTX_INPROC_SERVER, &IID_IFilterMapper2, (LPVOID*)&pFM2);
if (SUCCEEDED(hr)) { @@ -585,6 +584,7 @@ static HRESULT register_filters(struct r REGFILTER2 rf2; REGFILTERPINS2* prfp2; int i; + for (i = 0; list->pins[i].flags != 0xFFFFFFFF; i++) ; rf2.dwVersion = 2; rf2.dwMerit = list->merit; @@ -598,6 +598,7 @@ static HRESULT register_filters(struct r REGPINTYPES* lpMediatype; CLSID* lpClsid; int j, nbmt; + for (nbmt = 0; list->pins[i].mediatypes[nbmt].majortype; nbmt++) ; /* Allocate a single buffer for regpintypes struct and clsids */ lpMediatype = (REGPINTYPES*) CoTaskMemAlloc(nbmt*(sizeof(REGPINTYPES) + 2*sizeof(CLSID))); @@ -627,10 +628,17 @@ static HRESULT register_filters(struct r prfp2[i].clsPinCategory = NULL; }
+ if (FAILED(hr)) { + ERR("failed to register with hresult 0x%lx\n", hr); + break; + } + hr = IFilterMapper2_RegisterFilter(pFM2, list->clsid, list->name, NULL, list->category, NULL, &rf2);
- while (i--) + while (i) { CoTaskMemFree((REGPINTYPES*)prfp2[i-1].lpMediaType); + i--; + } CoTaskMemFree(prfp2); } }
On Thu, 2005-01-20 at 22:21, Mike Hearn wrote:
On Thu, 2005-01-20 at 20:32 +0100, Paul Vriens wrote:
Sorry, didn't help.
I'm going to try Rob's suggestions now.
This patch fixes it for me.
Mike Hearn mh@codeweavers.com Fix heap corruption in quartz server registration, add some whitespace, break out of loop if out of memory
--- dlls/quartz/regsvr.c (revision 109) +++ dlls/quartz/regsvr.c (local) @@ -577,7 +577,6 @@ static HRESULT register_filters(struct r IFilterMapper2* pFM2 = NULL;
CoInitialize(NULL);
hr = CoCreateInstance(&CLSID_FilterMapper2, NULL, CLSCTX_INPROC_SERVER, &IID_IFilterMapper2, (LPVOID*)&pFM2);
if (SUCCEEDED(hr)) {
@@ -585,6 +584,7 @@ static HRESULT register_filters(struct r REGFILTER2 rf2; REGFILTERPINS2* prfp2; int i;
for (i = 0; list->pins[i].flags != 0xFFFFFFFF; i++) ; rf2.dwVersion = 2; rf2.dwMerit = list->merit;@@ -598,6 +598,7 @@ static HRESULT register_filters(struct r REGPINTYPES* lpMediatype; CLSID* lpClsid; int j, nbmt;
@@ -627,10 +628,17 @@ static HRESULT register_filters(struct r prfp2[i].clsPinCategory = NULL; }
if (FAILED(hr)) {ERR("failed to register with hresult 0x%lx\n", hr);break;}hr = IFilterMapper2_RegisterFilter(pFM2, list->clsid, list->name, NULL, list->category, NULL, &rf2);
while (i--)
while (i) {i--;} CoTaskMemFree(prfp2);
Let's hear it for Mike !!
Works here as well. I don't get any ERR output so I presume it's just the change of the while() that already fixed it?
Cheers and thanks,
Paul.
Hi Mike,
Mike Hearn wrote:
On Thu, 2005-01-20 at 20:32 +0100, Paul Vriens wrote:
Sorry, didn't help.
I'm going to try Rob's suggestions now.
This patch fixes it for me.
Thanks! :-)
Mike Hearn mh@codeweavers.com Fix heap corruption in quartz server registration, add some whitespace, break out of loop if out of memory
--- dlls/quartz/regsvr.c (revision 109) +++ dlls/quartz/regsvr.c (local) @@ -577,7 +577,6 @@ static HRESULT register_filters(struct r IFilterMapper2* pFM2 = NULL;
CoInitialize(NULL);
hr = CoCreateInstance(&CLSID_FilterMapper2, NULL, CLSCTX_INPROC_SERVER, &IID_IFilterMapper2, (LPVOID*)&pFM2);
if (SUCCEEDED(hr)) {
@@ -585,6 +584,7 @@ static HRESULT register_filters(struct r REGFILTER2 rf2; REGFILTERPINS2* prfp2; int i;
for (i = 0; list->pins[i].flags != 0xFFFFFFFF; i++) ; rf2.dwVersion = 2; rf2.dwMerit = list->merit;@@ -598,6 +598,7 @@ static HRESULT register_filters(struct r REGPINTYPES* lpMediatype; CLSID* lpClsid; int j, nbmt;
@@ -627,10 +628,17 @@ static HRESULT register_filters(struct r prfp2[i].clsPinCategory = NULL; }
if (FAILED(hr)) {ERR("failed to register with hresult 0x%lx\n", hr);break;}
You should free memory pointed by prfp2 in that case.
hr = IFilterMapper2_RegisterFilter(pFM2, list->clsid, list->name, NULL, list->category, NULL, &rf2);
while (i--)
while (i) {i--;}
Good catch!
CoTaskMemFree(prfp2);} }
Bye, Christian
Paul Vriens wrote:
On Thu, 2005-01-20 at 18:21, Robert Shearman wrote:
If it's heap corruption then it could well depend on the order of allocations, so it could be timing dependent. I've attached a patch that poisons the apartment structure after when it is freed so that hopefully any use-after-free will become more obvious. Could you apply it and see what the results are? Does the X Error stop? Do we now get warnings about accessing a handle of 0xcccccccc (run with warn+all for this)?
Rob
I can remember having a conversation with Christian Costa for the same kind of error.
That was after he added some extra filter registration in quartz/regsvr.c. I just played around with the CoInitialize in register_filters. I changed CoInitialize(NULL) into CoInitializeEx(NULL, COINIT_MULTITHREADED) and the error was gone.
When I do the same change now, the X Error is gone as well. Does this give you a clue?
Not much I'm afraid. When using an MTA the window isn't created, so there is no chance of an X Error during its destruction. There is something you could try though. Can you move the "if (apt->win) DestroyWindow(apt->win);" line in COM_ApartmentRelease to after the LIST_FOR_EACH_SAFE list iteration? If the apartment pointer is bad then we should easily die in the list iteration (the iteration will only end once it finds a pointer back to the original list, which is very unlikely if we are using a bad apartment pointer). I also noticed in the log that you are getting a few heap warnings. Could you try scattering a few of these debug statements throughout the devenum self-registration code (particularly around any COM calls): if (!HeapValidate(GetProcessHeap(), 0, NULL)) DebugBreak(); This should then dump you to the debugger close to where the heap corruption occurred. If you can narrow it down to one line in devenum (i.e. it succeeds before the call, fails after) then can you let me know which line that is and that should be a big clue to finding out what is going wrong.
Thanks, Rob
-
Alexandre Julliard -
Christian Costa -
Mike Hearn -
Paul Vriens -
Rob Shearman -
Robert Shearman