http://bugs.winehq.org/show_bug.cgi?id=27929
Summary: Bus error in create_alpha_bitmap on Mac OS X 10.7 Lion with Xcode 4.1 Product: Wine Version: 1.3.25 Platform: x86-64 OS/Version: other Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: camillo.lugaresi+wine@gmail.com
I have compiled Wine 1.3.25 on Mac OS X 10.7, with the latest developer tools installed (Xcode 4.1). Trying to launch any wine program, even winemine, results in it crashing with the message "Bus error: 10". Running wine inside gdb, and with WINEDEBUG=+relay, shows that the crash occurs while doing:
0045:Call user32.LoadIconA(403b0000,403b5a84 "WINEMINE") ret=403b1899
Specifically, it crashes inside create_alpha_bitmap, soon after the call to StretchDIBits returns, inside the loop that does alpha premultiplication. By disassembling I found that the crash occurs in the line
ptr[0] = ptr[0] * alpha / 255;
when attempting to write back the value into ptr[0]. It occurs on the very first iterations of the loop.
I tried googling a bit, and this seems to be the same problem that was discussed here: http://www.winehq.org/pipermail/wine-devel/2011-January/088553.html
But that conversation was back in January, and it's unclear if any resolution was reached. Anyway, since this problem seems to make Wine completely unusable on Lion, and can be reproduced entirely within wine, I think it should be considered both easy to reproduce (as long as you have access to a Mac) and very urgent to fix
http://bugs.winehq.org/show_bug.cgi?id=27929
camillo.lugaresi+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |user32
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #1 from Alexandre Julliard julliard@winehq.org 2011-07-28 10:08:43 CDT --- That's a DIB section exception, it should be caught and handled. It sounds like your signal handlers are broken, probably a compiler issue. Building Wine on Lion is not recommended at this point unless you know what you are doing.
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #2 from camillo.lugaresi+wine@gmail.com 2011-07-28 10:54:00 CDT --- (In reply to comment #1)
That's a DIB section exception, it should be caught and handled. It sounds like your signal handlers are broken, probably a compiler issue. Building Wine on Lion is not recommended at this point unless you know what you are doing.
And if you knew what you were doing, what would you do? Is this problem being discussed anywhere? I might be able to help.
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2011-07-28 11:00:23 CDT --- (In reply to comment #2)
And if you knew what you were doing, what would you do? Is this problem being discussed anywhere? I might be able to help.
Not really. I played a little with the developer preview but other priorities interfered. Essentially you'll have to debug it and figure out what's wrong with the signal handling.
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #4 from camillo.lugaresi+wine@gmail.com 2011-07-28 11:16:13 CDT --- (In reply to comment #3)
(In reply to comment #2)
And if you knew what you were doing, what would you do? Is this problem being discussed anywhere? I might be able to help.
Not really. I played a little with the developer preview but other priorities interfered. Essentially you'll have to debug it and figure out what's wrong with the signal handling.
signal_init_process is called, and the disassembly looks right: it seems to be calling sigaction with the the correct pointer to segv_handler. However, segv_handler is not called when the signal is received. I'll keep investigating.
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #5 from camillo.lugaresi+wine@gmail.com 2011-07-28 15:11:30 CDT --- (In reply to comment #4)
signal_init_process is called, and the disassembly looks right: it seems to be calling sigaction with the the correct pointer to segv_handler. However, segv_handler is not called when the signal is received. I'll keep investigating.
Actually, the signal handler is probably getting called, but gdb on OS X messes us the translation between mach exceptions (EXC_BAD_ACCESS in this case) and UNIX signals (SIGBUS), so it cannot be used to step into signal handlers.
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #6 from camillo.lugaresi+wine@gmail.com 2011-07-28 23:04:07 CDT --- (In reply to comment #5)
(In reply to comment #4)
signal_init_process is called, and the disassembly looks right: it seems to be calling sigaction with the the correct pointer to segv_handler. However, segv_handler is not called when the signal is received. I'll keep investigating.
Actually, the signal handler is probably getting called, but gdb on OS X messes us the translation between mach exceptions (EXC_BAD_ACCESS in this case) and UNIX signals (SIGBUS), so it cannot be used to step into signal handlers.
Ok, the solution to this problem is to give gdb the obscure command "set dont-handle-bad-access 1" before running the program. This stops gdb from intercepting the Mach exception, allowing the normal translation into a UNIX signal to work, and then the signal handler is called.
This does not solve the crash, but at least should make it much easier to debug. After doing this and setting a breakpoint at the beginning of segv_handler, I was able to step through its assembly. It seems to be working correctly. Indeed, I can just give the "continue" command a few times, to go through the page faults, and eventually the program runs correctly!
In fact, I can set "handle SIGBUS nostop", delete the breakpoint, and the program runs correctly in gdb. Strange.
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #7 from camillo.lugaresi+wine@gmail.com 2011-08-01 07:21:22 CDT --- create_alpha_bitmap is a red herring, it seems. The real crash occurs while loading libraries, and the signal handlers is not called because it has not even been installed at that point. Unfortunately, this crash does not occur when running with gdb, so it's hard to debug.
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #8 from camillo.lugaresi+wine@gmail.com 2011-08-01 07:54:46 CDT --- (In reply to comment #7)
create_alpha_bitmap is a red herring, it seems. The real crash occurs while loading libraries, and the signal handlers is not called because it has not even been installed at that point. Unfortunately, this crash does not occur when running with gdb, so it's hard to debug.
Using DYLD_PRINT_LIBRARIES and export DYLD_PRINT_INITIALIZERS, wine built on 10.7 behaves like this:
----8<---- dyld: loaded: /usr/X11/lib/libXdmcp.6.dylib dyld: calling initializer function 0x95667700 in /usr/lib/libSystem.B.dylib Bus error: 10 ----8<----
The one build on 10.6 (but run on the same 10.7 machine) does:
----8<---- dyld: loaded: /usr/X11/lib/libXdmcp.6.dylib dyld: calling initializer function 0x95667700 in /usr/lib/libSystem.B.dylib dyld: calling initializer function 0x957090c0 in /usr/lib/libc++.1.dylib ----8<----
and continues with the other initializers. So it seems that the crash really occurs inside libSystem's initializer, which is the first to be called.
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #9 from camillo.lugaresi+wine@gmail.com 2011-08-01 07:58:33 CDT --- Using the wine executable built on 10.6 with the libraries built on 10.7 doesn't crash. This reduces the target enormously!
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #10 from camillo.lugaresi+wine@gmail.com 2011-08-01 13:29:48 CDT --- Created an attachment (id=35775) --> (http://bugs.winehq.org/attachment.cgi?id=35775) makes wine link correctly on lion
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #11 from camillo.lugaresi+wine@gmail.com 2011-08-01 13:30:48 CDT --- This fixes the problem. Can I change the bug directly from unconfirmed to fixed? When can I expect this patch to make it into a dev release?
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #12 from Alexandre Julliard julliard@winehq.org 2011-08-01 13:47:55 CDT --- A bug is not fixed until the patch is committed, and patches have to be sent to wine-patches to be applied. Of course it would really need a configure check to determine if the flag is necessary (or even supported).
http://bugs.winehq.org/show_bug.cgi?id=27929
--- Comment #13 from camillo.lugaresi+wine@gmail.com 2011-08-02 08:18:47 CDT --- (In reply to comment #12)
A bug is not fixed until the patch is committed, and patches have to be sent to wine-patches to be applied. Of course it would really need a configure check to determine if the flag is necessary (or even supported).
Done.
http://bugs.winehq.org/show_bug.cgi?id=27929
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #14 from Austin English austinenglish@gmail.com 2011-08-02 14:29:52 CDT --- (In reply to comment #13)
(In reply to comment #12)
A bug is not fixed until the patch is committed, and patches have to be sent to wine-patches to be applied. Of course it would really need a configure check to determine if the flag is necessary (or even supported).
Done.
Fixed by http://source.winehq.org/git/wine.git/commitdiff/0b5dcbafea44bf68ec72494cc9f...
http://bugs.winehq.org/show_bug.cgi?id=27929
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2011-08-05 12:38:10 CDT --- Closing bugs fixed in 1.3.26.