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
