[Bug 18672] New: Free application WinBUGS crashes right away when executed within a Linux OS using any Wine version > 1.1.12.
http://bugs.winehq.org/show_bug.cgi?id=18672
Summary: Free application WinBUGS crashes right away when executed within a Linux OS using any Wine version > 1.1.12. Product: Wine Version: 1.1.22 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: s.conti@gmx.co.uk
WinBUGS, a freely downloadable (URL: http://www.mrc-bsu.cam.ac.uk/bugs/) statistical software available under Windows only, can be successfully run on Linux by means of Wine.
However the application would produce an outright crash if used with any Wine version later than (and including) 1.1.13; utilisation of Wine versions up to 1.1.12 would give no problem.
Following is the full outcome of my regression testing attempt:
== 11c1d7a0e7ff8d4713c8177dce4ba54781e69ead is first bad commit commit 11c1d7a0e7ff8d4713c8177dce4ba54781e69ead Author: Nikolay Sivov bunglehead@gmail.com Date: Wed Jan 7 11:58:29 2009 +0300
ole32: Fix return value for DefaultHandler_GetMiscStatus.
:040000 040000 c714b9a367c8894e61a1c528a1e014e66e3a35c9 5e1fd0df7307b205054fdc2316e17b3b56dda223 M dlls ==
Very many thanks in advance for taking your time and attention.
http://bugs.winehq.org/show_bug.cgi?id=18672
Stefano s.conti@gmx.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Free application WinBUGS |WinBUGS crashes under Linux |crashes right away when |with any Wine version > |executed within a Linux OS |1.1.12. |using any Wine version > | |1.1.12. |
http://bugs.winehq.org/show_bug.cgi?id=18672
Stefano s.conti@gmx.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |critical
http://bugs.winehq.org/show_bug.cgi?id=18672
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bunglehead@gmail.com Severity|critical |normal
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2009-05-28 08:37:43 --- http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
http://bugs.winehq.org/show_bug.cgi?id=18672
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression
http://bugs.winehq.org/show_bug.cgi?id=18672
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW URL| |http://www.mrc-bsu.cam.ac.u | |k/bugs/winbugs/WinBUGS14.ex | |e Component|-unknown |ole32 Ever Confirmed|0 |1
--- Comment #2 from Ken Sharp kennybobs@o2.co.uk 2009-05-28 13:07:18 --- Confirming.
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #3 from Ken Sharp kennybobs@o2.co.uk 2009-05-28 13:08:15 --- Created an attachment (id=21385) --> (http://bugs.winehq.org/attachment.cgi?id=21385) Screenshot of error
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com 2009-05-28 13:21:34 --- (In reply to comment #0)
Following is the full outcome of my regression testing attempt:
== 11c1d7a0e7ff8d4713c8177dce4ba54781e69ead is first bad commit
Does reverting help?
If it does a detail trace needed to get parameter set.
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #5 from Stefano s.conti@gmx.co.uk 2009-05-29 05:42:52 --- (In reply to comment #4)
Does reverting help?
If it does a detail trace needed to get parameter set.
This is what I've done at the command line from the "wine-git" folder in response to the above suggestion; I insert my comments within the following code between square brackets ([]):
== $ git show 11c1d7a0e7ff8d4713c8177dce4ba54781e69ead | patch -p1 -R patching file dlls/ole32/defaulthandler.c patching file dlls/ole32/tests/ole2.c Hunk #1 succeeded at 1423 (offset 39 lines).
$ CC="ccache gcc" ./configure --verbose && make depend && make [omitted] Wine build complete.
$ ./wine ../.WinBUGS14/WinBUGS14.exe & [OK, WinBUGS doesn't crash]
$ git reset --hard HEAD HEAD is now at 22a277c... msi: Fix some memory leaks. ==
Hope the above information is exhaustive and helpful; if not please assist.
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #6 from Austin English austinenglish@gmail.com 2009-05-29 10:15:52 --- Please attach a +ole trace.
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #7 from Nikolay Sivov bunglehead@gmail.com 2009-05-31 05:09:42 --- Created an attachment (id=21446) --> (http://bugs.winehq.org/attachment.cgi?id=21446) Adds PBrush CLSID
Hi, Stefano.
It seems to me that the real problem is missed registry entry for that class. This registry file from XP works fine for me.
Don't know actually how could we include it in our default registry settings but it looks like we don't have to implement mspaint for that - you'll see instead: --- err:ole:CoGetClassObject no class object {0003000a-0000-0000-c000-000000000046} could be created for context 0x3 ---
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #8 from Stefano s.conti@gmx.co.uk 2009-06-01 03:41:15 --- (In reply to comment #7)
Created an attachment (id=21446)
--> (http://bugs.winehq.org/attachment.cgi?id=21446) [details]
Adds PBrush CLSID
Hi, Stefano.
It seems to me that the real problem is missed registry entry for that class. This registry file from XP works fine for me.
Don't know actually how could we include it in our default registry settings but it looks like we don't have to implement mspaint for that - you'll see instead:
err:ole:CoGetClassObject no class object {0003000a-0000-0000-c000-000000000046} could be created for context 0x3
Dear Nikolay,
thank you for your insight, and for including the +ole trace; unfortunately I'm afraid my still limited competence of Wine prevents me from fully understanding your remark. Does this mean that the bug will be resolved via somehow circumventing it, rather than addressing it directly? Thank you for clarifying.
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #9 from Nikolay Sivov bunglehead@gmail.com 2009-06-01 04:00:05 --- (In reply to comment #8)
thank you for your insight, and for including the +ole trace; unfortunately I'm afraid my still limited competence of Wine prevents me from fully understanding your remark.
Hi, Stefano.
Use this first of all http://wiki.winehq.org/FAQ. It has lot of common questions answered.
I posted a registry export file which contains a registration entry for class your app is requesting. It looks like it's a minimal needed info to start.
You could easily apply it running: --- regedit pbrush.reg ---
Full ole log seems to be unnecessary but you can always use the FAQ on available debug channels and command lines.
Does this mean that the bug will be resolved via somehow circumventing it, rather than addressing it directly? Thank you for clarifying.
I don't think that it's a hack actually. The commit your app is failing on makes an internal Wine test pass, so these changes are reasonable. It works without it cause a problem with registration info loss is hidden by always-successful return code (S_OK).
http://bugs.winehq.org/show_bug.cgi?id=18672
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|ole32 |programs
--- Comment #10 from Nikolay Sivov bunglehead@gmail.com 2010-01-01 12:09:29 --- Actually this isn't an ole problem, it caused by missed mspaint.exe application and its registration data (application fails to read it from registry).
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #11 from Austin English austinenglish@gmail.com 2010-01-01 14:01:56 --- (In reply to comment #10)
Actually this isn't an ole problem, it caused by missed mspaint.exe application and its registration data (application fails to read it from registry).
FWIW, someone sent an mspaint implementation a while back: http://www.winehq.org/pipermail/wine-patches/2008-November/064261.html
I'm not sure why it was rejected, last iteration had no comments. My guess was it was that nothing depended on it, so AJ didn't want to add the maintenance burden. But if an app needs it, perhaps he'd change his mind...
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #12 from Nikolay Sivov bunglehead@gmail.com 2010-01-01 18:18:27 --- (In reply to comment #11)
I'm not sure why it was rejected, last iteration had no comments. My guess was it was that nothing depended on it, so AJ didn't want to add the maintenance burden. But if an app needs it, perhaps he'd change his mind...
App doesn't need it to start. Registration info present in registry is enough to fix this crash. When I tried this a half of year ago I was in doubt to send a a patch to create registry entry cause I thought it's a crappy solution to add such class info without working implementation, I might be wrong of course. Probably AJ's opinion is what we need here.
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #13 from Austin English austinenglish@gmail.com 2010-01-01 18:30:10 --- (In reply to comment #11)
(In reply to comment #10)
Actually this isn't an ole problem, it caused by missed mspaint.exe application and its registration data (application fails to read it from registry).
FWIW, someone sent an mspaint implementation a while back: http://www.winehq.org/pipermail/wine-patches/2008-November/064261.html
I'm not sure why it was rejected, last iteration had no comments. My guess was it was that nothing depended on it, so AJ didn't want to add the maintenance burden. But if an app needs it, perhaps he'd change his mind...
Err, now I know why. The code was pretty broken, and didn't work ;-). I'm attaching a cleaned up version of the patch.
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #14 from Austin English austinenglish@gmail.com 2010-01-01 18:42:30 --- Created an attachment (id=25496) --> (http://bugs.winehq.org/attachment.cgi?id=25496) mspaint implementation
Unicodified, compiler errors fixed and some minor code cleanup. Not fully implemented, and uses 100% of cpu between itself and wineserver...
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #15 from Nikolay Sivov bunglehead@gmail.com 2010-01-01 19:15:59 --- (In reply to comment #14)
and uses 100% of cpu between itself and wineserver...
Not good :).
Anyway this shouldn't be accepted - all file loading and saving is in wincodecs now, so mspaint should use gdiplus probably (or directly windowscodecs).
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #16 from Austin English austinenglish@gmail.com 2010-01-01 20:19:55 --- (In reply to comment #15)
(In reply to comment #14)
and uses 100% of cpu between itself and wineserver...
Not good :).
Seems to be: ==8696== Invalid read of size 1 ==8696== at 0x40269A0: memcpy (mc_replace_strmem.c:497) ==8696== by 0x4B97662: GetDIBits (in /home/austin/wine-git/dlls/gdi32/gdi32.dll.so) ==8696== by 0x4A83E11: CopyImage (cursoricon.c:2733) ==8696== by 0x4949671: BM_Copy (bitmap.c:518) ==8696== by 0x495753B: PAINT_FileNew (paint.c:267) ==8696== by 0x4956CAD: WinMain (main.c:1483) ==8696== by 0x495A41E: main (in /home/austin/wine-git/programs/mspaint/mspaint.exe.so) ==8696== Address 0x7c040000 is not stack'd, malloc'd or (recently) free'd
The bitmap.c call is: HBITMAP BM_Copy(HBITMAP hbm) { return (HBITMAP)CopyImage(hbm, IMAGE_BITMAP, 0, 0, LR_COPYRETURNORG); }
Changing that to return 0 chills down the cpu, but then the image is black, not white. The code in paint.c needs to be fixed, it seems.
Anyway this shouldn't be accepted - all file loading and saving is in wincodecs now, so mspaint should use gdiplus probably (or directly windowscodecs).
Well, I'll leave that for someone else. I've done most of the grunt work ;-).
http://bugs.winehq.org/show_bug.cgi?id=18672
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=18672
Poor Yorick org.winehq@pooryorick.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |org.winehq@pooryorick.com
--- Comment #17 from Poor Yorick org.winehq@pooryorick.com 2010-05-22 00:57:35 --- I don't think this has anything to do with mspaint, but rather, WinBUGS requires dcom98 ole overrides. I'm running WinBUGS-1.4.3 with no problem under wine-1.1.44. My notes here: http://www.ynform.org/w/Pub/WinbugsUnderWine
http://bugs.winehq.org/show_bug.cgi?id=18672
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #18 from Dan Kegel dank@kegel.com 2011-07-08 13:19:46 CDT --- Is this still a problem with wine from git? I was able to install the app, start it, and use it to update itself to winebugs 1.4.3 per http://www.mrc-bsu.cam.ac.uk/bugs/winbugs/WinBUGS14_cumulative_patch_No3_06_...
If this is still a problem, please give us a recipe including exact mouseclicks and keystrokes.
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #19 from Stefano s.conti@gmx.co.uk 2011-07-10 16:00:43 CDT --- It's been a while since I've last had any problem with running WinBUGS through Wine; at the time Winetricks did the trick, and to date is working like a charm even after a number of updates.
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #20 from Dan Kegel dank@kegel.com 2011-07-10 16:19:13 CDT --- Stefano, can you verify that winbugs works in a clean wineprefix without any winetricks?
http://bugs.winehq.org/show_bug.cgi?id=18672
--- Comment #21 from Stefano s.conti@gmx.co.uk 2011-07-11 16:44:53 CDT --- (In reply to comment #20)
Stefano, can you verify that winbugs works in a clean wineprefix without any winetricks?
No Winetricks is now on my system, and I'm running WinBUGS based on Wine 1.3.14 without a hitch.
http://bugs.winehq.org/show_bug.cgi?id=18672
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #22 from Dan Kegel dank@kegel.com 2011-07-11 16:47:13 CDT --- Reported fixed.
http://bugs.winehq.org/show_bug.cgi?id=18672
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #23 from Alexandre Julliard julliard@winehq.org 2011-07-22 12:45:39 CDT --- Closing bugs fixed in 1.3.25.
-
wine-bugs＠winehq.org