Re: Executing wine over make segfaults.
# wine --version Works!
But:
Makefile --------- test: wine --version ---------
Then run: #make test
Wine will segfault!
I am having the same problem. I use wine to run a compiler from a Makefile. A few months ago, it worked fine, but recently it stopped working. I even downgraded to versions that had worked before, but without success. I have a few older systems that rarely get updated and are working fine, so I was not too concerned about it, but when I saw that 0.9.24 worked, I thought I was back in business.... except it doesn't work from make. The system is gentoo linux (2.6.18-gentoo-r1) wine compiled like this: ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --sysconfdir=/etc/wine --without-curses --without-opengl --with-x --disable-trace --disable-debug --build=i686-pc-linux-gnu
Do you have any special kernel compile options in use?
It's gentoo, so everything is custom compiled, but I try to keep it pretty vanilla. I don't think I have stack-protector on unless that is the default for gcc-4.1.1 I could try installing an older version of gcc or an older kernel and see if that helps. Any other ideas? Thanks for your time. _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
The system is gentoo linux (2.6.18-gentoo-r1)
I recently tried 2.6.18.1 kernel and wine stoped working. Then I downgraded to 2.6.16.18 and wine working fine now. After doing some important work, I will recompile 2.6.18.1 again with same .config and will see what happens. But because difference of .config between my 2.6.16.18 and 2.6.18.1 wasn't very big I think this is Wine problem (probably not Linux problem because everything works perfectly with new kernel). But I must try exactly same .config to be sure (only some deprecated options will be automatically excluded by "make menuconfig").
I could try installing an older version of gcc or an older kernel and see if that helps.
If downloading 39M isn't big problem for you then please try kernel 2.6.16.18. You can download it here: http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.18.tar.bz2
L. Rahyen wrote:
The system is gentoo linux (2.6.18-gentoo-r1)
I recently tried 2.6.18.1 kernel and wine stoped working. Then I downgraded to 2.6.16.18 and wine working fine now.
I'm using a custom built 2.6.18.1 on Debian Unstable/AMD64 now, and Wine works fine for me, so this is unlikely to be a Wine problem. Mike
I recently tried 2.6.18.1 kernel and wine stoped working. Then I downgraded to 2.6.16.18 and wine working fine now.
I'm using a custom built 2.6.18.1 on Debian Unstable/AMD64 now, and Wine works fine for me, so this is unlikely to be a Wine problem.
I compiled 2.6.18.1 with same .config. As expected, Wine stoped working. I don't know yet why exactly this happens but fact is that with same configuration under 2.6.18.1 kernel Wine doesn't work. As you said you have 2.6.18.1 and working Wine. So please tell your compiler, X server versions and compilation options for Wine. Also I very appreciate if you send me your .config file so I can try it on my system (I use Debian testing amd64 distribution). I have errors like these ones when I try to launch something with Wine: fixme:seh:check_no_exec No-exec fault triggered at 0x401000, enabling work-around fixme:seh:check_no_exec No-exec fault triggered at 0x4c8ad4, enabling work-around err:seh:setup_exception stack overflow 40 bytes in thread 0009 eip f7c9e9ff esp 00230fd8 stack 0x231000-0x340000 Some applications even open window but soon after these messages crash. Factually, all my Windows apps crash! Only exceptions that I found are winecfg and notepad, but everything else including all my games, viewers, players and editors crash. Under 2.6.16.18 Wine works perfectly. P.S. I use gcc 4.0.2 and Wine compiled by following commands: LDFLAGS="-L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32" ./configure \ --x-libraries=/emul/ia32-linux/usr/X11R6/lib/ --x-includes=/emul/ia32-linux/usr/X11R6/include --with-x && \ make depend && \ make all && \ sudo make install;
...with same configuration under 2.6.18.1 kernel Wine doesn't work. ... I have errors like these ones when I try to launch something with Wine:
fixme:seh:check_no_exec No-exec fault triggered at 0x401000, enabling work-around fixme:seh:check_no_exec No-exec fault triggered at 0x4c8ad4, enabling work-around err:seh:setup_exception stack overflow 40 bytes in thread 0009 eip f7c9e9ff esp 00230fd8 stack 0x231000-0x340000
This seems to be Wine-related problem (but not neccessary Wine bug) because everything else works fine with 2.6.18.1 kernel; I'm not alone who have strange problems with Wine under 2.6.18 kernel. Any ideas why this happening? Or at least give me some clue how I can debug this. Only thing I can say this is definitely not kernel configuration problem, and isn't "simple bug" in Wine because under 2.6.16.18 it works perfectly. What I want is at least find true source of this problem so I can file proper bug report and maybe try to fix this myself.
This seems to be Wine-related problem (but not neccessary Wine bug) because everything else works fine with 2.6.18.1 kernel; I'm not alone who have strange problems with Wine under 2.6.18 kernel.
No, you are not. I've posted a very similar problem with wine & 2.6.18 a couple of weeks ago. Just to recall, my experiences with the problem: 1) Not every windows app causes wine to segfault. There are fairly complex, networked apps, which work flawlessly (DC++), other ones, much more simple, cause wine to crash, like wine's itself "rundll.exe setupapi.dll" when it tries to create a fresh .wine directory. Please see my post to wine-devel dated Oct 11, with subject "wine segfaulting" for details. There is even a strace snippet. 2) It crashes almost identically on both i386 and x86_64 architectures, with the same applications. 3) As demonstrated in 1), it does so even in the .wine directory build process, which means that no DLL overrides or other user-broken things can be involved. 4) No user/system settings can change this. Tried to increase various ulimits, manipulate (disable) exec-shield etc. Just the only solution known to me is to boot 2.6.17 or less, which I cannot normally because of other features I currently need from 2.6.18. 5) I'm testing wine on the system it was built on (with 2.6.18). It should ensure maximum compatibility with its kernel (I'm using live kernel includes for <linux/*> and <asm/*>). However, it works when transferred to another system running 2.6.17. I'm ready to perform some debugging; however, currently I don't know where to start. With regards, Pavel Troller
On Mon, Nov 06, 2006 at 08:46:40AM +0100, Pavel Troller wrote:
This seems to be Wine-related problem (but not neccessary Wine bug) because everything else works fine with 2.6.18.1 kernel; I'm not alone who have strange problems with Wine under 2.6.18 kernel.
No, you are not. I've posted a very similar problem with wine & 2.6.18 a couple of weeks ago. Just to recall, my experiences with the problem: 1) Not every windows app causes wine to segfault. There are fairly complex, networked apps, which work flawlessly (DC++), other ones, much more simple, cause wine to crash, like wine's itself "rundll.exe setupapi.dll" when it tries to create a fresh .wine directory. Please see my post to wine-devel dated Oct 11, with subject "wine segfaulting" for details. There is even a strace snippet. 2) It crashes almost identically on both i386 and x86_64 architectures, with the same applications. 3) As demonstrated in 1), it does so even in the .wine directory build process, which means that no DLL overrides or other user-broken things can be involved. 4) No user/system settings can change this. Tried to increase various ulimits, manipulate (disable) exec-shield etc. Just the only solution known to me is to boot 2.6.17 or less, which I cannot normally because of other features I currently need from 2.6.18. 5) I'm testing wine on the system it was built on (with 2.6.18). It should ensure maximum compatibility with its kernel (I'm using live kernel includes for <linux/*> and <asm/*>). However, it works when transferred to another system running 2.6.17. I'm ready to perform some debugging; however, currently I don't know where to start.
Can you get backtraces in gdb ? I am using a 2.6.18 based openSUSE 10.2 Beta1 kernel and Wine works fine there. (AMD64 however). Ciao, Marcus
I am using a 2.6.18 based openSUSE 10.2 Beta1 kernel and Wine works fine there. (AMD64 however).
Your NoExec protection is on or off? And question to all: is there someone with new (2.6.18.x) vanilla kernel (downloaded from kernel.org), noexec=on and perfectly working Wine? If yes, then please send me your .config, tell your gcc versions - I will try to figure out why problems happens to Wine with new kernels then. If I don't recieve answer I will assume that everyone with 2.6.18.x kernel (or higher) andNoExec protection cannot use Wine. This is speculative of course and not neccessary true but I need to have "starting point". Theoretically everyone with NoExec turned on (this is default) with 2.6.18.x kernel will end up with not working Wine. But situation may vary with compiler version. If so this is important to know so if someone have 2.6.18.x vanilla kernel with NoExec protection turned on (default) and working Wine please reply. Also I wish to say that this bug isn't just security problem "add-noexec=off option-and-here-you-go!". Most users (especcialy who didn't tried Wine before) with new kernels will think that there is no solution (they will think that application simply doesn't work under Wine) - so most applications will not work for them including virtually all games (at least all my games that work perfectly with 2.6.16.18 crashes with 2.6.18.1). Very few programs will work (for example: notepad, proxomitron, mdict) but most will fail (for example: Unreal Tournament, Postal 2, XnView, IrfanView and many, many others). This is very bad and I think this is major compatibility problem.
fixme:seh:check_no_exec No-exec fault triggered at 0x401000, enabling work-around
Are you using SeLinux or some other patches? If so, please try building your kernel from the vanilla Linux kernel.org sources.
Hi Mike! I take you very seriously, I know that you are a real wine guru, but I know that those messages are not related to the segfaulting problem. 1) These messages appear only on a x86_64 architecture. On i386 the crash is the same but the messages are not there. 2) There are other apps, which work perfectly, although they emit the same messages. 3) I'm using exec-shield patch, but I can disable it (for sure, tested by the pax testing suite) using a procfs entry. Even with exec-shield disabled the crash is still there, and in 2.6.17, even with exec-shield enabled, there is no crash. With regards, Pavel Troller
"Pavel Troller" <patrol(a)sinus.cz> wrote:
fixme:seh:check_no_exec No-exec fault triggered at 0x401000, enabling work-around
Are you using SeLinux or some other patches? If so, please try building your kernel from the vanilla Linux kernel.org sources.
Hi Mike! I take you very seriously, I know that you are a real wine guru, but I know that those messages are not related to the segfaulting problem.
1) These messages appear only on a x86_64 architecture. On i386 the crash is the same but the messages are not there. 2) There are other apps, which work perfectly, although they emit the same messages. 3) I'm using exec-shield patch, but I can disable it (for sure, tested by the pax testing suite) using a procfs entry. Even with exec-shield disabled the crash is still there, and in 2.6.17, even with exec-shield enabled, there is no crash.
Then probably the only way to unbreak the broken apps is to add noexec=off to the kernel command line. -- Dmitry.
On Mon, Nov 06, 2006 at 10:29:22PM +0800, Dmitry Timoshkov wrote:
3) I'm using exec-shield patch, but I can disable it (for sure, tested by the pax testing suite) using a procfs entry. Even with exec-shield disabled the crash is still there, and in 2.6.17, even with exec-shield enabled, there is no crash. Then probably the only way to unbreak the broken apps is to add noexec=off to the kernel command line.
this is what i did - and also suggest quite some time ago him(?)/list. i had the same problem since .16 kernels (unstable(~) gentoo-source ebuild). since that change everything works fine (.18 now). -- cu
this is what i did - and also suggest quite some time ago him(?)/list. i had the same problem since .16 kernels (unstable(~) gentoo-source ebuild). since that change everything works fine (.18 now).
Hi! Yes, you did, and you did correctly. I just rebooted the x86_64 machine with noexec=off. The app runs with no problems. Does it mean that something changed in noexec between .17 and .18 ? Why wine worked well with noexec and 2.6.17 ? But it's really wrong: I don't want to compromise my security because of running wine. Is there a chance to fix this in wine, for example by ordering executability for every memory allocation ? With regards, Pavel Troller
On Mon, Nov 06, 2006 at 04:40:48PM +0100, Pavel Troller wrote:
this is what i did - and also suggest quite some time ago him(?)/list. i had the same problem since .16 kernels (unstable(~) gentoo-source ebuild). since that change everything works fine (.18 now).
Hi! Yes, you did, and you did correctly. I just rebooted the x86_64 machine with noexec=off. The app runs with no problems. Does it mean that something changed in noexec between .17 and .18 ? Why wine worked well with noexec and 2.6.17 ? But it's really wrong: I don't want to compromise my security because of running wine. Is there a chance to fix this in wine, for example by ordering executability for every memory allocation ? With regards, Pavel Troller
We just have to find out _why_ it breaks. Should not be too hard with some backtraces or similar. Ciao, Marcus
We just have to find out _why_ it breaks. Should not be too hard with some backtraces or similar.
Hi! Today I tried to generate a backtrace. However, I simply failed. I've recompiled wine with full debug, and reinstalled. Then I installed the newest gdb (6.5), because my older one (6.4) seemed a bit unstable. Then, I did the following: 1) patrol(a)tangens:/mnt/cd$ gdb wine GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run 100_prazskych_zajimavosti.exe Starting program: /opt/wine/bin/wine 100_prazskych_zajimavosti.exe Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1208980992 (LWP 19254)] [New Thread -1208984688 (LWP 19257)] [Thread -1208984688 (LWP 19257) exited] Cannot find user-level thread for LWP 19254: generic error gdb then hung and had to be killed. It should be noted that gdb works with standard Linux binaries normally. 2) patrol(a)tangens:~$ wine /mnt/cd/100_prazskych_zajimavosti.exe fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:ole:CoResumeClassObjects stub Segmentation fault (core dumped) patrol(a)tangens:~$ gdb -c core.19668 /mnt/cd/100_prazskych_zajimavosti.exe GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". warning: core file may not match specified executable file. warning: shared library handler failed to enable breakpoint (no debugging symbols found) Core was generated by `/mnt/cd/100_prazskych_zajimavosti.exe '. Program terminated with signal 11, Segmentation fault. #0 0x00876440 in ?? () (gdb) bt #0 0x00876440 in ?? () #1 0x0000000b in ?? () #2 0x7ffddc8c in ?? () #3 0x7ffddd0c in ?? () #4 0x0000000b in ?? () #5 0x00000000 in ?? () (gdb) First I tried 'gdb -c <core> wine' but it told me that the core was generated by another executable, and stated the windows .exe file (you can see the same in the above output too). Backtrace is, however, the same in both cases, and, as you can see, totally bogus. I really don't know how to get better results now. Any hints available ? With regards, Pavel Troller
On Tue, Nov 07, 2006 at 06:44:31AM +0100, Pavel Troller wrote:
We just have to find out _why_ it breaks. Should not be too hard with some backtraces or similar.
Hi! Today I tried to generate a backtrace. However, I simply failed. I've recompiled wine with full debug, and reinstalled. Then I installed the newest gdb (6.5), because my older one (6.4) seemed a bit unstable. Then, I did the following: 1) patrol(a)tangens:/mnt/cd$ gdb wine GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run 100_prazskych_zajimavosti.exe Starting program: /opt/wine/bin/wine 100_prazskych_zajimavosti.exe Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1208980992 (LWP 19254)] [New Thread -1208984688 (LWP 19257)] [Thread -1208984688 (LWP 19257) exited] Cannot find user-level thread for LWP 19254: generic error
gdb then hung and had to be killed. It should be noted that gdb works with standard Linux binaries normally.
2) patrol(a)tangens:~$ wine /mnt/cd/100_prazskych_zajimavosti.exe fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:font:WineEngCreateFontInstance just using first face for now fixme:ole:CoResumeClassObjects stub Segmentation fault (core dumped) patrol(a)tangens:~$ gdb -c core.19668 /mnt/cd/100_prazskych_zajimavosti.exe GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1".
warning: core file may not match specified executable file.
warning: shared library handler failed to enable breakpoint (no debugging symbols found) Core was generated by `/mnt/cd/100_prazskych_zajimavosti.exe '. Program terminated with signal 11, Segmentation fault. #0 0x00876440 in ?? () (gdb) bt #0 0x00876440 in ?? () #1 0x0000000b in ?? () #2 0x7ffddc8c in ?? () #3 0x7ffddd0c in ?? () #4 0x0000000b in ?? () #5 0x00000000 in ?? () (gdb)
First I tried 'gdb -c <core> wine' but it told me that the core was generated by another executable, and stated the windows .exe file (you can see the same in the above output too). Backtrace is, however, the same in both cases, and, as you can see, totally bogus.
I really don't know how to get better results now. Any hints available ?
It is usuyally generated from wine-pthread gdb wine-pthread core.19668 bt If it still does not show a backtrace, try: x /i $eip info registers to show the current instruction + registers. Ciao, Marcus
Hi!
It is usuyally generated from wine-pthread
gdb wine-pthread core.19668 bt It showed the following: patrol(a)tangens:~$ gdb wine-pthread core.19668 GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
warning: core file may not match specified executable file. warning: Can't read pathname for load map: Input/output error. Reading symbols from /opt/wine/lib/libwine.so.1...done. Loaded symbols for /opt/wine/bin/../lib/libwine.so.1 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 ... and many similar lines for every library involved Reading symbols from /opt/wine/lib/wine/urlmon.dll.so...done. Loaded symbols for /opt/wine/bin/../lib/wine/urlmon.dll.so Core was generated by `/mnt/cd/100_prazskych_zajimavosti.exe '. Program terminated with signal 11, Segmentation fault. #0 0x00876440 in ?? () (gdb)
If it still does not show a backtrace, try:
No it doesn't, the backtrace is just as dummy as before.
x /i $eip info registers
to show the current instruction + registers.
OK, particular success: (gdb) x /i $eip 0x876440: Cannot access memory at address 0x876440 (gdb) info registers eax 0x33f5cc 3405260 ecx 0x0 0 edx 0x3904a2 3736738 ebx 0x33f9ff 3406335 esp 0x7ffddc80 0x7ffddc80 ebp 0x33f634 0x33f634 esi 0x3904a0 3736736 edi 0x1 1 eip 0x876440 0x876440 eflags 0x210206 [ PF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x33 51 gs 0x3b 59 (gdb)
Ciao, Marcus
With regards, Pavel Troller
Then probably the only way to unbreak the broken apps is to add noexec=off to the kernel command line.
I saw a few others say that this worked around the problem, so I rebooted and added noexec=off ... I still get the segfault running wine from make. _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/
I saw a few others say that this worked around the problem, so I rebooted and added noexec=off ... I still get the segfault running wine from make.
Unfortunatelly I cannot reproduce your problem. Under 2.6.18.1 with noexec=off simple Makefile posted by Jimmy W works fine for me. So in order to debug problem you may try the following: strace make - it may show some useful info about segfault but of course to find exactly why and where segfault happens you must attach to Wine process with your debugger.
participants (8)
-
Christoph Frick -
Dmitry Timoshkov -
L. Rahyen -
Lee Harr -
Marcus Meissner -
Marcus Meissner -
Mike McCormack -
Pavel Troller