https://bugs.winehq.org/show_bug.cgi?id=40892
Bug ID: 40892 Summary: Charmap.exe crashes on close after copying a character Product: Wine Version: 1.9.13 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs@winehq.org Reporter: dexgerig@gmail.com Distribution: ---
Created attachment 54982 --> https://bugs.winehq.org/attachment.cgi?id=54982 Backtrace of crash
Window's charmap application will crash if you try to close it after selecting and copying a character from it's list.
Steps to reproduce. 1. Create clean 32-bit prefix using wine version 1.9.13
2. Obtain a copy of Window's charmap.exe and the required dll getuname.dll. (I got mine from my Windows XP machine)
md5sum: ac9fa2ba34225342a8897930503ae12f charmap.exe 60b9959d333c3d11255d8695d2685430 getuname.dll
3. Open charmap.exe
4. Click the select button then click the copy button.
5. Close exit out of the application.
Backtrace will be attached in this post.
Looking at the backtrace it seems to crash in the clipboard uninitialization function "OLEClipbrd_UnInitialize". Specifically in the inlined function "IDataObject_Release". Here is the relevant code.
void OLEClipbrd_UnInitialize(void) { ole_clipbrd *clipbrd = theOleClipboard;
TRACE("()\n");
if ( clipbrd ) { static const WCHAR ole32W[] = {'o','l','e','3','2',0}; HINSTANCE hinst = GetModuleHandleW(ole32W);
if ( clipbrd->window ) { DestroyWindow(clipbrd->window); UnregisterClassW( clipbrd_wndclass, hinst ); }
IStream_Release(clipbrd->marshal_data); if (clipbrd->src_data) IDataObject_Release(clipbrd->src_data); HeapFree(GetProcessHeap(), 0, clipbrd->cached_enum); HeapFree(GetProcessHeap(), 0, clipbrd); theOleClipboard = NULL; } }
static FORCEINLINE ULONG IDataObject_Release(IDataObject* This) { return This->lpVtbl->Release(This); }
https://bugs.winehq.org/show_bug.cgi?id=40892
--- Comment #1 from Dexter Gerig dexgerig@gmail.com --- Created attachment 54983 --> https://bugs.winehq.org/attachment.cgi?id=54983 ole debug log
https://bugs.winehq.org/show_bug.cgi?id=40892
--- Comment #2 from Dexter Gerig dexgerig@gmail.com --- I forgot to mention that even though you might see wine-staging in the build path for my wine setup I had wine-staging disabled for this test. Although this did occur in wine-staging as well.
https://bugs.winehq.org/show_bug.cgi?id=40892
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #3 from winetest@luukku.com --- Do you think you can make a patch for this? Even the required changes to make this work and some other could form the patch.
https://bugs.winehq.org/show_bug.cgi?id=40892
zaplo00@mailfence.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zaplo00@mailfence.com
--- Comment #4 from zaplo00@mailfence.com --- This happens in wine 3.10
https://bugs.winehq.org/show_bug.cgi?id=40892
Joe ThePillenwerfer@GMail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ThePillenwerfer@GMail.com
--- Comment #5 from Joe ThePillenwerfer@GMail.com --- Created attachment 64754 --> https://bugs.winehq.org/attachment.cgi?id=64754 Terminal output from running charmap.exe
I don't know why the antepenultimate line says "Windows 7" as I have set charmap.exe to run under XP in winecfg
https://bugs.winehq.org/show_bug.cgi?id=40892
Joe ThePillenwerfer@GMail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #64754|Terminal output from |Terminal output from description|running charmap.exe |running charmap.exe on Wine | |4.0.1 on Debian 9.9 32-bit
https://bugs.winehq.org/show_bug.cgi?id=40892
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com --- Is this really a valid test case, with non-redistributable binaries copied from Windows installation?