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:
- 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.
- It crashes almost identically on both i386 and x86_64 architectures, with the same applications.
- 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.
- 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.
- 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