https://bugs.winehq.org/show_bug.cgi?id=42009
Bug ID: 42009 Summary: Mentor Graphics DK Design Suite crashes on clipboard copy Product: Wine Version: 2.0-rc2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs@winehq.org Reporter: felix.huber@schyf.de Distribution: ---
Created attachment 56448 --> https://bugs.winehq.org/attachment.cgi?id=56448 Backtrace of the crash
Wine crashes when selecting text in the DK editor and trying to copy it to the clipboard using ctrl-C.
This behavior started with wine 1.9.19, all versions up to 2.0-rc2 are affected. I could track down the problem to the call of IDataObject_Addref(data) in function set_src_dataobject of clipboard.c in dlls/ole32.
https://bugs.winehq.org/show_bug.cgi?id=42009
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #1 from winetest@luukku.com --- Does this program have a free trial that can be used to reproduce the issue?
This would help a lot, if you could do this.
https://wiki.winehq.org/Regression_Testing
Could be related/dupe, bug 41710 but they claim that the regression started different version.
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #2 from felix.huber@schyf.de --- Unfortunately, there is no free version, it's flexlm node locked. I also checked bug 41710 first, but it seems different. The issue started with the reworked clipboard functions of V1.9.19. It looks like IDataObject_AddRef is accessing fields in the IDataObject *data in the wrong way.
Can I do some tests, like dump the memory there the data pointer points to?
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #3 from winetest@luukku.com --- You can even do test program to indicate the problem if you have tools and knowledge how to do it.
If you haven't read this, maybe worth to look at
https://www.winehq.org/docs/winedev-guide/wine-debugger
http://source.winehq.org/git/wine.git/shortlog
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #4 from felix.huber@schyf.de --- That's what I read first in order find the failing function and check what was recently changed. But it seems like clipboard.c was not changed, so maybe some other functions cause the IDataObject to be broken? How could I check this?
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #5 from felix.huber@schyf.de --- I have to correct myself: 1.9.19 is the last working version. I am trying to find the differences against this one
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #6 from felix.huber@schyf.de --- I did some line by line debugging: Start the app with winedbg, set breakpoint at OleSetClipboard and EmptyClipboard, continue In OleSetClipboard the IDataObject *data->lpVtbl is fine until the call to EmptyClipboard was made. After that data is altered and points to an invalid Vtbl. Somewhere within EmptyClipboard, OleIsCurrentClipboard gets called, where data is still fine. I managed once to make it work by single stepping through OpenClipboard for some lines, but could not reproduce that. Can this be a race condition?
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #7 from winetest@luukku.com --- This was useful feature that I wasnt aware of http://source.winehq.org/git/wine.git/tags
You can pick any wine version since you said it was working 1.9.19 I picked wine 1.9.20
http://source.winehq.org/git/wine.git/blobdiff/b488a67bafbfe231579bfd2a47f45...
To me bug 41273 looks promising.
Are you able to compile wine yourself? Reverting that commit could fix this bug. Could be some other change, but that looks promising since it's clipboard related fix.
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #8 from felix.huber@schyf.de --- I could track down the problem to line 529 in server/clipboard.c clipboard->owner = clipboard->open_win;
If I comment out this line, the data pointer is not altered and clipboard copy and paste works again.
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #9 from felix.huber@schyf.de --- I did a regression test. This is the failing commit:
a52d09198d3264c9c712a70de57446e6183957dd winex11: Run a single clipboard manager thread per window station, inside the explorer process.
Signed-off-by: Alexandre Julliard julliard@winehq.org
:040000 040000 45fbe6c77a0c4836053c848abbeb101af80a8486 cfaa1551580061b7c795bc3dd986636a79390181 M dlls
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #10 from Alexandre Julliard julliard@winehq.org --- Created attachment 56622 --> https://bugs.winehq.org/attachment.cgi?id=56622 X11 clipboard polling
Please give this a try.
https://bugs.winehq.org/show_bug.cgi?id=42009
felix.huber@schyf.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #11 from felix.huber@schyf.de --- Works fine again.
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #12 from felix.huber@schyf.de --- With the patch applied of course.
https://bugs.winehq.org/show_bug.cgi?id=42009
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|RESOLVED |REOPENED Ever confirmed|0 |1
--- Comment #13 from Nikolay Sivov bunglehead@gmail.com --- This patch hasn't been committed yet. So the bug is still valid.
https://bugs.winehq.org/show_bug.cgi?id=42009
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |a52d09198d3264c9c712a70de57 | |446e6183957dd Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #14 from Alexandre Julliard julliard@winehq.org --- Thank you for testing. I believe that this is a bug in the Qt libraries. Basically what happens in Qt is:
clipboard->m_data = data; OleSetClipboard( data );
and in the WM_DRAWCLIPBOARD handler:
if (!OleIsCurrentClipboard( clipboard->m_data )) free m_data;
But it's possible that it would receive a WM_DRAWCLIPBOARD from a previous change, and free the data while it's still inside OleSetClipoard.
I believe it would crash on Windows too if the clipboard changed at just the wrong time. But on Wine, because we check for updates synchronously with OpenClipboard, the WM_DRAWCLIPBOARD is pretty much guaranteed to happen at the wrong time.
https://bugs.winehq.org/show_bug.cgi?id=42009
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sergi_g_12@hotmail.com
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- *** Bug 41710 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=42009
Vit vit9696@avp.su changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vit9696@avp.su
https://bugs.winehq.org/show_bug.cgi?id=42009
thefugazi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thefugazi@gmail.com
--- Comment #16 from thefugazi@gmail.com --- The above patch also fixed the crashing I was experiencing with TextAloud - http://nextup.com. Not only does the app no longer crash when pasting clipboard contents, but the 'monitoring clipboard' in TextAloud also now works as it should. Previously, I had to copy text, then open TextAloud and interact with the app - before it would begin reading the clipboard contents.
https://bugs.winehq.org/show_bug.cgi?id=42009
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |d4f8366fa61b0f7a20b2b71272a | |40ef09e617140 Status|REOPENED |RESOLVED Resolution|--- |FIXED
--- Comment #17 from Alexandre Julliard julliard@winehq.org --- It should be fixed by 1137e3502dc7e27e9db64c18436bfbc27a763820 and d4f8366fa61b0f7a20b2b71272a40ef09e617140.
It can still potentially crash if you try to copy quickly after copying something else from an X11 app, but that's probably good enough.
https://bugs.winehq.org/show_bug.cgi?id=42009
--- Comment #18 from Ken Thomases ken@codeweavers.com --- This should also be fixed with the Mac driver by 525c0b17952425142e2a4fce5ca358b4f2f8a73e and 5f5807cbfec59fe5aebf07badc0ab4732710b79b.
https://bugs.winehq.org/show_bug.cgi?id=42009
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 2.0-rc5.