https://bugs.winehq.org/show_bug.cgi?id=38829
Bug ID: 38829 Summary: This was reported a way back, fixed, now recurs Product: Wine Version: 1.7.46 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comdlg32 Assignee: wine-bugs@winehq.org Reporter: d_baron@012.net.il Distribution: ---
Bug filed with Debian 790340@bugs.debian.org, 790340-submitter@bugs.debian.org Re-filed here at their request.
All file menus crash out on click OK, cancel, etc. Backtrace at Debian link.
https://bugs.winehq.org/show_bug.cgi?id=38829
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW See Also| |http://bugs.debian.org/7903 | |40 Distribution|--- |Debian Summary|This was reported a way |Jammer Pro 6 crashes on |back, fixed, now recurs |file open Ever confirmed|0 |1
--- Comment #1 from Rosanne DiMesio dimesio@earthlink.net --- Link for the Debian bug that's not a mailto link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790340
The Debian bug report incorrectly says this is the same as a previous Wine bug, bug 30945. However, the problem in that bug (Jammer Pro 6 Demo won't install without native IE7) is not the same as what is being reported now (Jammer Pro 6 crashes on file menu).
The demo can be downloaded from http://www.soundtrek.com/content/downloads/demos/jammer_pro_6_demo_setup.zip. The app installs without problems to a clean, 32 bit wineprefix, but needs mfc42 to run.
I can confirm the crash on trying to open a file in 1.7.46, but not on other file menu items (save and export are disabled in the demo, so I couldn't test those).
https://bugs.winehq.org/show_bug.cgi?id=38829
--- Comment #2 from Rosanne DiMesio dimesio@earthlink.net --- Created attachment 51768 --> https://bugs.winehq.org/attachment.cgi?id=51768 Jammer backtrace
https://bugs.winehq.org/show_bug.cgi?id=38829
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.soundtrek.com/co | |ntent/downloads/demos/jamme | |r_pro_6_demo_setup.zip
https://bugs.winehq.org/show_bug.cgi?id=38829
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@fds-team.de
--- Comment #3 from Michael Müller michael@fds-team.de --- Created attachment 51775 --> https://bugs.winehq.org/attachment.cgi?id=51775 Patch to add a check if fodInfos is NULL
I attached a patch which fixes the issue. I am not sure though if there is a better way to handle this problem.
I will explain what causes the issue, maybe someone comes up with a better approach. So here is what happens:
1. The applications calls GetOpenFileNameA and defines a custom template with custom controls (!). 2. The dialog is created and FileOpenDlgProc95 is called with WM_INITDIALOG. The function saves the custom dialog information: SetPropA(hwnd, FileOpenDlgInfosStr, fodInfos); 3. The users closes the dialog (for example by clicking Cancel). DIALOG_DoDialogBox leaves the message loop and calls FileOpenDlgProc95 with WM_DESTROY which removes the custom dialog information again: RemovePropA(hwnd, FileOpenDlgInfosStr); 4. DIALOG_DoDialogBox destroys the dialog window using DestroyWindow. DestroyWindow first destroys the child windows and sends WM_DESTROY to one of the custom controls. 5. The custom control receives the message and calls SetWindowText on an edit control: 6. The edit control changes the text and informs the parent window using SendMessage (in EDIT_WM_SetText). The parent window in this case is the dialog window. 7. The dialog proc is called (although we already left the message loop) and FILEDLG95_OnWMCommand tries to process the message. 8. FILEDLG95_OnWMCommand tries to get the custom dialog information and deferences them: FileOpenDlgInfos *fodInfos = GetPropA(hwnd,FileOpenDlgInfosStr); [...] fodInfos->DlgInfos.dwDlgProp &= ~FODPROP_USEVIEW; 9. CRASH ;-)
Obviously the dialog proc function was not supposed to be called any more. I am not sure if one of those window functions is supposed to fail since we are already destroying the window or if the application is really doing something dangerous here. We can workaround the problem by checking if fodInfos is NULL in FILEDLG95_OnWMCommand (as I did in the patch). However, this wouldn't fix the issue for other window messages like WM_SIZE. Maybe we should add such checks everywhere in FileOpenDlgProc95?
https://bugs.winehq.org/show_bug.cgi?id=38829
--- Comment #4 from David Baron d_baron@012.net.il --- I am not presently compiling Wine locally (I have in the past so could do so again), so cannot really test this out.
As a matter or principle, all such functions should check their pointers and boundaries and either throw an orderly exception or exit silently (or with some stderr message). One never knows what other developers will throw at one :-)
This bug has been a long and often fixed/recurring problem with this application.
https://bugs.winehq.org/show_bug.cgi?id=38829
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
https://bugs.winehq.org/show_bug.cgi?id=38829
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |bunglehead@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=38829
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |b8d1e929e7d9d847b898c05e951 | |12be12292adf7 Status|NEW |RESOLVED Assignee|bunglehead@gmail.com |wine-bugs@winehq.org Resolution|--- |FIXED
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com --- Marking fixed, b8d1e929e7d9d847b898c05e95112be12292adf7.
https://bugs.winehq.org/show_bug.cgi?id=38829
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.5.