wine problems on a 64bit system
Hi! As some of you know, I'm experimenting with my new 64bit systems. I've found that there are problems running a lot of applications, which normally run on a 32bit system. A typical example is IL2 Sturmovik Forgotten Battles game. On a 32bit system, with the latest wine CVS (even compiled on a 64bit system) it runs flawlessly. On a 64bit system, it just prints fixme:seh:check_no_exec No exec fault triggered at 0x6d4d08b0, enabling work-around but the workaround seems to be unefficient, because nothing more happens. With a +relay, it shows that the program is looping, executing 0009:Call msvcrt._except_handler3(7fb2faa0,7fb2fba0,7fb2f7d4,7fb2f714) ret=7bc54d65 0009:Ret msvcrt._except_handler3() retval=00000000 ret=7bc54d65 and nothing more, ad infinitum. The machines are running very similar kernels. Both are hardened with exec-shield, but even disabling it on a 64bit by 'echo 0 >/proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with exec-shield enabled (and doesn't print the no-exec message). Are there chances to fix this issue ? Or is it a system problem ? With regards, Pavel Troller
Hi Pavel, I've only slightly followed wine-devel recently On 5/31/06, Pavel Troller <patrol(a)sinus.cz> wrote:
As some of you know, I'm experimenting with my new 64bit systems. I've found that there are problems running a lot of applications, which normally run on a 32bit system. A typical example is IL2 Sturmovik Forgotten Battles game. On a 32bit system, with the latest wine CVS (even compiled on a 64bit system) it runs flawlessly. On a 64bit system, it just prints fixme:seh:check_no_exec No exec fault triggered at 0x6d4d08b0, enabling work-around but the workaround seems to be unefficient, because nothing more happens. With a +relay, it shows that the program is looping, executing 0009:Call msvcrt._except_handler3(7fb2faa0,7fb2fba0,7fb2f7d4,7fb2f714) ret=7bc54d65 0009:Ret msvcrt._except_handler3() retval=00000000 ret=7bc54d65 and nothing more, ad infinitum. The machines are running very similar kernels. Both are hardened with exec-shield, but even disabling it on a 64bit by 'echo 0 >/proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with exec-shield enabled (and doesn't print the no-exec message). Are there chances to fix this issue ? Or is it a system problem ?
Are you using a stock Fedora kernel? They are all (x86-64) built with SMP support. Would it be possible to check with a custom built non-smp kernel to see if you have the same behavior? I've been looking in to this matter myself but its been slow going because I lack a 64bit system here. Can you run a strace on a winelib process and send us the results with both the SMP and non-smp kernels? Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Hi Pavel, Hi Steven! I've only slightly followed wine-devel recently
Are you using a stock Fedora kernel? No. I'm using vanilla kernels just with exec-shield patch from Ingo Molnar. I'm not using any well-known distro. They are all (x86-64) built with SMP support. My ones are also built with SMP support, because both the 64bit machines have dual-core CPUs. One of them is Pentium-D and the second is Dual Opteron. Would it be possible to check with a custom built non-smp kernel to see if you have the same behavior? OK. These machines build a kernel in 3 minutes, no problem to try to disable SMP and verify. However, the 32bit one is also SMP :-); it's MSI K7D Master board populated with 2 Athlons MP. It works perfectly and it's ideal for gaming, because one CPU handles Xserver and similar and the other runs the game :-). wine has no problems with it. I've been looking in to this matter myself but its been slow going because I lack a 64bit system here. Can you run a strace on a winelib process and send us the results with both the SMP and non-smp kernels? Will do. With regards, Pavel Troller
Pavel Troller <patrol(a)sinus.cz> writes:
Hi! As some of you know, I'm experimenting with my new 64bit systems. I've found that there are problems running a lot of applications, which normally run on a 32bit system. A typical example is IL2 Sturmovik Forgotten Battles game. On a 32bit system, with the latest wine CVS (even compiled on a 64bit system) it runs flawlessly. On a 64bit system, it just prints fixme:seh:check_no_exec No exec fault triggered at 0x6d4d08b0, enabling work-around but the workaround seems to be unefficient, because nothing more happens. With a +relay, it shows that the program is looping, executing 0009:Call msvcrt._except_handler3(7fb2faa0,7fb2fba0,7fb2f7d4,7fb2f714) ret=7bc54d65 0009:Ret msvcrt._except_handler3() retval=00000000 ret=7bc54d65 and nothing more, ad infinitum. The machines are running very similar kernels. Both are hardened with exec-shield, but even disabling it on a 64bit by 'echo 0 >/proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with exec-shield enabled (and doesn't print the no-exec message). Are there chances to fix this issue ? Or is it a system problem ?
It may be that your kernel doesn't allow writable memory to be made executable, in which case we can't do anything about it. Or maybe the workaround is simply broken... It may also be possible to make that section executable some other way, you'll need to investigate what that memory address corresponds to in the app. -- Alexandre Julliard julliard(a)winehq.org
Hi Alexandre, many thanks that you are also looking at this problem.
It may be that your kernel doesn't allow writable memory to be made executable, in which case we can't do anything about it. Or maybe the workaround is simply broken... It may also be possible to make that section executable some other way, you'll need to investigate what that memory address corresponds to in the app.
Running the app, it shows tv(a)co:~/il2sturmovikfb$ wine il2fb.exe fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around Looking at /proc/<pid>/maps, it shows root(a)co:/proc/14647# cat maps |grep 6d4d 6d4cf000-6d4d0000 rw-p 6d4cf000 00:00 0 6d4d0000-6d4d1000 rwxp 6d4d0000 00:00 0 6d4d1000-6d4e3000 rw-p 6d4d1000 00:00 0 It looks that this page IS writable as well as executable. However, there is nothing more about it, no indication of which part of the app it corresponds to. Just a global data/BSS section ? BTW the problem happens very early during startup, even before an Xserver is accessed, so trying it from the text console (without $DISPLAY defined) gives exactly the same results as from Xterm. But now I'm unsure, maybe we are on a false track. I just examined +relay output again and I've found that immediately after the No-exec message the program seems to continue normally. The problem (exception loop in msvcrt) occurs many thousands lines later. I'm attaching preceding cca 1500 lines of the log. With regards, Pavel Troller
Pavel Troller <patrol(a)sinus.cz> writes:
But now I'm unsure, maybe we are on a false track. I just examined +relay output again and I've found that immediately after the No-exec message the program seems to continue normally. The problem (exception loop in msvcrt) occurs many thousands lines later. I'm attaching preceding cca 1500 lines of the log.
It sounds like the no-exec workaround worked fine, and that you have some other problem. What does a +seh trace look like? -- Alexandre Julliard julliard(a)winehq.org
Pavel Troller <patrol(a)sinus.cz> writes:
But now I'm unsure, maybe we are on a false track. I just examined +relay output again and I've found that immediately after the No-exec message the program seems to continue normally. The problem (exception loop in msvcrt) occurs many thousands lines later. I'm attaching preceding cca 1500 lines of the log.
It sounds like the no-exec workaround worked fine, and that you have some other problem. What does a +seh trace look like?
Hi Alexandre! +seh shows the following: trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d08b0 trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d08b0 trace:seh:raise_exception eax=00000001 ebx=7fe02cd8 ecx=7fe02cd8 edx=00000003 esi=7fe02cd8 edi=6d4e0e90 trace:seh:raise_exception ebp=7fb2fd70 esp=7fb2fd68 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010293 trace:seh:call_stack_handlers calling handler at 0x401f00 code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d08b0 handler=0x401f00 0x7fb2fa44 0x7fb2f984 semi-stub trace:seh:_except_handler3 filter = 0x401e62 trace:seh:_XcptFilter (-1073741819,0x7fb2f8c0) trace:seh:_except_handler3 filter returned CONTINUE_SEARCH trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch trace:seh:call_stack_handlers handler at 0x401f00 returned 1 trace:seh:call_stack_handlers calling handler at 0x7b82be80 code=c0000005 flags=0 fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around trace:seh:call_stack_handlers handler at 0x7b82be80 returned 0 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4db3ef trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4db3ef trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4db3ef handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d5d7b trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d5d7b trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d5d7b handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 It looks that the first exception is the No-exec, then there is one more lonely one (at 0x6d4db3ef) and the third one (at 0x6d4d5d7b) is the first invocation of the looping one - this one repeats in the log at the same address forever. With regards, Pavel Troller
On Thu, Jun 01, 2006 at 01:42:37PM +0200, Pavel Troller wrote:
Pavel Troller <patrol(a)sinus.cz> writes:
But now I'm unsure, maybe we are on a false track. I just examined +relay output again and I've found that immediately after the No-exec message the program seems to continue normally. The problem (exception loop in msvcrt) occurs many thousands lines later. I'm attaching preceding cca 1500 lines of the log.
It sounds like the no-exec workaround worked fine, and that you have some other problem. What does a +seh trace look like?
Hi Alexandre! +seh shows the following:
trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d08b0 trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d08b0 trace:seh:raise_exception eax=00000001 ebx=7fe02cd8 ecx=7fe02cd8 edx=00000003 esi=7fe02cd8 edi=6d4e0e90 trace:seh:raise_exception ebp=7fb2fd70 esp=7fb2fd68 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010293 trace:seh:call_stack_handlers calling handler at 0x401f00 code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d08b0 handler=0x401f00 0x7fb2fa44 0x7fb2f984 semi-stub trace:seh:_except_handler3 filter = 0x401e62 trace:seh:_XcptFilter (-1073741819,0x7fb2f8c0) trace:seh:_except_handler3 filter returned CONTINUE_SEARCH trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch trace:seh:call_stack_handlers handler at 0x401f00 returned 1 trace:seh:call_stack_handlers calling handler at 0x7b82be80 code=c0000005 flags=0 fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around trace:seh:call_stack_handlers handler at 0x7b82be80 returned 0 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4db3ef trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4db3ef trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4db3ef handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d5d7b trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d5d7b trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d5d7b handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0
It looks that the first exception is the No-exec, then there is one more lonely one (at 0x6d4db3ef) and the third one (at 0x6d4d5d7b) is the first invocation of the looping one - this one repeats in the log at the same address forever.
Please check the audit log whether a SELINUX audit event happened. (/var/log/audit/audit.log I think.) Ciao, Marcus
Pavel Troller <patrol(a)sinus.cz> writes:
It looks that the first exception is the No-exec, then there is one more lonely one (at 0x6d4db3ef) and the third one (at 0x6d4d5d7b) is the first invocation of the looping one - this one repeats in the log at the same address forever.
Sounds like the whole code section is non-executable. Check where this section comes from using +module and/or winedump. -- Alexandre Julliard julliard(a)winehq.org
It looks that the first exception is the No-exec, then there is one more lonely one (at 0x6d4db3ef) and the third one (at 0x6d4d5d7b) is the first invocation of the looping one - this one repeats in the log at the same address forever.
Sounds like the whole code section is non-executable. Check where this section comes from using +module and/or winedump.
Hi Alexandre! By making +seh,+module dump and then grepping for 6d4, I've found the following interesting excerpts: At first: trace:module:load_native_dll Trying native dll L"Z:\\home\\tv\\il2sturmovikfb\\bin\\hotspot\\jvm.dll" trace:module:map_image mapped PE file at 0x6d420000-0x6d4ef000 trace:module:map_image mapping section .text at 0x6d421000 off 1000 size 94000 virt 93dd0 flags 60000020 trace:module:map_image mapping section .rdata at 0x6d4b5000 off 95000 size 9000 virt 8ca7 flags 40000040 trace:module:map_image mapping section .data at 0x6d4be000 off 9e000 size 11000 virt 24638 flags c0000040 trace:module:map_image mapping section .reloc at 0x6d4e3000 off af000 size c000 virt bf20 flags 42000040 It looks, from this one, that 0x6d4dxxxx belongs to .data section of jvm.dll. And next: trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d08b0 trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d08b0 trace:seh:raise_exception eax=00000001 ebx=7fe02cf0 ecx=7fe02cf0 edx=00000003 esi=7fe02cf0 edi=6d4e0e90 trace:seh:raise_exception ebp=7fb2fd70 esp=7fb2fd68 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010293 trace:seh:call_stack_handlers calling handler at 0x401f00 code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d08b0 handler=0x401f00 0x7fb2fa44 0x7fb2f984 semi-stub trace:seh:_except_handler3 filter = 0x401e62 trace:seh:_XcptFilter (-1073741819,0x7fb2f8c0) trace:seh:_except_handler3 filter returned CONTINUE_SEARCH trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch trace:seh:call_stack_handlers handler at 0x401f00 returned 1 trace:seh:call_stack_handlers calling handler at 0x7b82be80 code=c0000005 flags=0 fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around trace:seh:call_stack_handlers handler at 0x7b82be80 returned 0 We already know this one. It's the first attempt to access this address range. Workaround has been tried to activate. And now: trace:module:MODULE_InitDLL (0x6d420000 L"jvm.dll",THREAD_ATTACH,(nil)) - CALL trace:module:MODULE_InitDLL (0x6d420000,THREAD_ATTACH,(nil)) - RETURN 1 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4db3ef trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4db3ef trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cf0 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4db3ef handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d5d7b trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d5d7b trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cf0 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d5d7b handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 Now we see another access to this area. According to /proc/<pid>/maps: root(a)co:/proc/28433# cat maps |grep 6d4 6d420000-6d421000 r--p 00000000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d421000-6d4b5000 r-xp 00001000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d4b5000-6d4be000 r--p 00095000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d4be000-6d4cf000 rw-p 0009e000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d4cf000-6d4d0000 rw-p 6d4cf000 00:00 0 6d4d0000-6d4d1000 rwxp 6d4d0000 00:00 0 6d4d1000-6d4e3000 rw-p 6d4d1000 00:00 0 6d4e3000-6d4ef000 r--p 000af000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll This page really is NOT executable. So, why the workaround has been activated just for one page (6d4d0000 - 6d4d1000) and not for the other ones, where it also should be ? Why this new page has not been worked-around ? With regards, Pavel Troller
On Thu, Jun 01, 2006 at 02:59:30PM +0200, Pavel Troller wrote:
root(a)co:/proc/28433# cat maps |grep 6d4 6d420000-6d421000 r--p 00000000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll
i run this game (il2+fb+ace+pf) on a opteron system quite well. i found the folling things helpfull - it might shed some more light on the whole thing: a) i have to run this game using win2k (or up - guess nt4 might also work) - it wont work using win98 b) when i configure EnableHardwareShaders=1 (?) in the conf.ini then the game crashes sooner or later (depending on the Water=XXX setting (3 is sooner, 2 is later)) with OutOfMemory exceptions in java. the game takes up to 3 gb ram virtual and a few 100mb resistant acording to "top". the box has 2gb real but i am not sure if i put 1gb or 2gb swap on - so it might actually really use "all my ram". i found it also quite amusing, that 3gb where used - where i guessed windows can only do 2gb per process without further handling (urban legend?). once i disable the hardware shaders the water looks dull within the game but serves my hours of fun without a problem -- cu
Pavel Troller <patrol(a)sinus.cz> writes:
This page really is NOT executable. So, why the workaround has been activated just for one page (6d4d0000 - 6d4d1000) and not for the other ones, where it also should be ? Why this new page has not been worked-around ?
Because the app exception handler ignores the exception instead of propagating it. That's broken IMO, but it would certainly be possible to unprotect a larger range on the first fault. -- Alexandre Julliard julliard(a)winehq.org
On Wed, 31 May 2006 07:26:37 +0200, Pavel Troller wrote:
The machines are running very similar kernels. Both are hardened with exec-shield, but even disabling it on a 64bit by 'echo 0 >/proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with exec-shield enabled (and doesn't print the no-exec message).
As a hack you can change the code so every range of memory that is mapped is mapped executable. thanks -mike
On 6/1/06, Alexandre Julliard <julliard(a)winehq.org> wrote:
Yes, I'm afraid we'll have to do that by default, there are too many broken binaries out there.
I think we've only seen a couple of such reports so far .... given that the exec bit was never enforced before now it wouldn't be surprising if there are lots of buggy apps out there but we don't seem to be seeing them yet. Perhaps for NX capable systems it could be an appdefault? The security enhancement it gives would be nice to have at least as an option for power users (yeah yeah I know, another pref ...) thanks -mike
participants (6)
-
Alexandre Julliard -
Christoph Frick -
Marcus Meissner -
Mike Hearn -
Pavel Troller -
Steven Edwards