Hi! I have a problem running wine on one of my machines. It's the same binary copy which I've compiled and which successfully runs on another ones. The problem is that many apps, which run on other machines, cause wine to segfault here. The first one doing so is "rundll.exe setupapi.dll...", invoked during wineprefixcreate process, so there is even a problem creating a fresh .wine directory. Simple apps, like winecfg and notepad, run well. Other ones don't. For some of them, wine dumps a lot of warnings before the segfault, but exactly the same warnings are emitted on another machines, where the app runs well. When the app fails, it even doesn't start to render its window. However, when a virtual desktop is to be used, it appears but it's still empty in the moment of the fault. I was trying to get a backtrace by generating a core file and then examining it with gdb. However, it always complains about the fact that the core was created by another binary being run, and reports the name of the windows executable, not anything like wine-*thread, which run the app. An attempt of dumping the bt ends up with many hundreds of illegal entries, mostly zeroes, some 0xFFFFFFFFs and other junk, and the bt is ended by an inaccessible memory somewhere at 0x7FFExxxx. Basic software (kernel, glibc, X11...) is very similar on all of the machines, and of recent dates. I've also used strace and examined it. It looks that the segfault comes to 2 threads simultaneously. Immediately before there are some mprotect() calls and mmap2(), which is successfull. The fault appears somewhere at 61k'th line, so the app did a bunch of things before the crash: Now I'm lost. Can anybody help me, what to try next to find the cause and solve the problem ? Many thanks in advance! With regards, Pavel Troller
[pid 4583] <... gettimeofday resumed> {1160539521, 267044}, NULL) = 0 [pid 4583] read(21, "\221\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\1\0\0\0\0\0\0\0\0"..., 64) = 64 [pid 4583] write(22, "\0\0\0\0\0\0\0\0\0\0\0\226\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64 <unfinished ...> [pid 4580] <... read resumed> "\0\0\0\0\0\0\0\0\0\0\0\226\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 [pid 4583] <... write resumed> ) = 64 [pid 4580] rt_sigprocmask(SIG_SETMASK, [], <unfinished ...> [pid 4583] epoll_wait(0x6, 0xbfb1b5dc, 0x80, 0x6c8f <unfinished ...> [pid 4580] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 4580] write(6, ";\3\5\0\205\0@\2\0\0\0\0\0\0\0\0\1\0\1\0<\0\2\0\205\0@"..., 80) = 80 [pid 4580] mmap2(0x390000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x390000 [pid 4580] shmget(IPC_PRIVATE, 3152, IPC_CREAT|0700) = 7143430 [pid 4580] shmat(7143430, 0, 0) = 0xb7f45000 [pid 4580] write(6, ";\3\5\0\206\0@\2\0\0\0\0\0\0\0\0\1\0\1\0005\30\4\0\207"..., 56) = 56 [pid 4580] read(6, "\1\1\10\3\0\0\0\0\5\0\240\1\0\0\0\0\0\0\0\0\0\0\0\0\10"..., 32) = 32 [pid 4580] shmctl(7143430, IPC_64|IPC_RMID, 0) = 0 [pid 4580] mprotect(0x390000, 4096, PROT_READ|PROT_WRITE) = 0 [pid 4580] write(6, "<\3\2\0\206\0@\0027\0\4\0\211\0@\2\207\0@\2\0\0\0\0", 24) = 24 [pid 4580] mprotect(0x390000, 4096, PROT_READ) = 0 [pid 4580] write(6, ";\3\5\0\211\0@\2\0\0\0\0\0\0\0\0\212\1\2\0\224\3\n\0\207"..., 64) = 64 [pid 4580] read(6, "\1\1\r\3\0\0\0\0\5\0\240\1\0\0\0\0\0\0\0\0\0\0\0\0\10L"..., 32) = 32 [pid 4580] mprotect(0x390000, 4096, PROT_NONE) = 0 [pid 4580] write(6, "8\3\6\0\211\0@\2\1\200\1\0\17\0\0\0\1\0\0\0\0\0\0\0F\0"..., 60) = 60 [pid 4580] write(6, ";\3\5\0\212\0@\2\0\0\0\0\0\0\0\0\1\0\1\0<\0\2\0\212\0@"..., 44) = 44 [pid 4580] write(6, ";\3\5\0\213\0@\2\0\0\0\0\0\0\0\0\212\1\1\0008\0\4\0\211"..., 88) = 88 [pid 4580] write(6, ";\3\5\0\214\0@\2\0\0\0\0\0\0\0\0\1\0\1\0<\0\2\0\214\0@"..., 52) = 52 [pid 4580] shmdt(0xb7f43000) = 0 [pid 4580] mmap2(0x3a0000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3a0000 [pid 4580] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 4580] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 4587] <... read resumed> 0x6cd9c6a4, 8) = ? ERESTARTSYS (To be restarted) [pid 4588] <... read resumed> 0x6151d4c4, 8) = ? ERESTARTSYS (To be restarted) [pid 4583] <... epoll_wait resumed> ) = 1 [pid 4587] +++ killed by SIGSEGV +++ PANIC: handle_group_exit: 4587 leader 4580 Process 4588 attached (waiting for parent) [pid 4580] +++ killed by SIGSEGV +++ [pid 4583] gettimeofday({1160539521, 270820}, NULL) = 0 [pid 4583] epoll_ctl(0x6, 0x2, 0x15, 0xbfb1b53c) = 0 [pid 4583] close(21) = 0 [pid 4583] close(22) = 0 [pid 4583] close(23) = 0 [pid 4583] epoll_wait(0x6, 0xbfb1b5dc, 0x80, 0x6c8b) = 3 [pid 4583] gettimeofday({1160539521, 271022}, NULL) = 0 [pid 4583] write(38, "\0\0\0\0\3\1\0\0", 8) = -1 EPIPE (Broken pipe) [pid 4583] --- SIGPIPE (Broken pipe) @ 0 (0) --- [pid 4583] epoll_ctl(0x6, 0x2, 0x24, 0xbfb1b53c) = 0 [pid 4583] close(36) = 0 [pid 4583] close(37) = 0 [pid 4583] close(38) = 0 [pid 4583] write(35, "\0\0\0\0\3\1\0\0", 8) = -1 EPIPE (Broken pipe) [pid 4583] --- SIGPIPE (Broken pipe) @ 0 (0) ---
Hi,
What kernel version/distro are you using? What about make test.
I had similar strange behavior with 2.6.18 (debian/unstable linux-image-2.6.18-1-686): wine segfaults in multiple situations. The strangest was: make test failed/segfaulted in ntdll, but running the test manually with runtest worked !?! The rest of the system was perfect stable. With 2.6.17 everything works fine.
I found some reports on the net having similar problems with 2.6.18. It looks like a memory layout issue.
Markus
Pavel Troller wrote:
Hi! I have a problem running wine on one of my machines. It's the same binary copy which I've compiled and which successfully runs on another ones. The problem is that many apps, which run on other machines, cause wine to segfault here. The first one doing so is "rundll.exe setupapi.dll...", invoked during wineprefixcreate process, so there is even a problem creating a fresh .wine directory. Simple apps, like winecfg and notepad, run well. Other ones don't. For some of them, wine dumps a lot of warnings before the segfault, but exactly the same warnings are emitted on another machines, where the app runs well. When the app fails, it even doesn't start to render its window. However, when a virtual desktop is to be used, it appears but it's still empty in the moment of the fault.
On Wed, Oct 11, 2006 at 11:32:47AM +0200, Markus Amsler wrote:
Hi,
What kernel version/distro are you using? What about make test.
I had similar strange behavior with 2.6.18 (debian/unstable linux-image-2.6.18-1-686): wine segfaults in multiple situations. The strangest was: make test failed/segfaulted in ntdll, but running the test manually with runtest worked !?! The rest of the system was perfect stable. With 2.6.17 everything works fine.
I found some reports on the net having similar problems with 2.6.18. It looks like a memory layout issue.
Is there a ulimit set? (ulimit -a) But I think we solved this specific problem already.
As for make test ... was the "exception" test the problem?
Ciao, Marcus
Marcus Meissner wrote:
On Wed, Oct 11, 2006 at 11:32:47AM +0200, Markus Amsler wrote:
Hi,
What kernel version/distro are you using? What about make test.
I had similar strange behavior with 2.6.18 (debian/unstable linux-image-2.6.18-1-686): wine segfaults in multiple situations. The strangest was: make test failed/segfaulted in ntdll, but running the test manually with runtest worked !?! The rest of the system was perfect stable. With 2.6.17 everything works fine.
I found some reports on the net having similar problems with 2.6.18. It looks like a memory layout issue.
Is there a ulimit set? (ulimit -a) But I think we solved this specific problem already.
there is, but 2.6.17, 2.6.18 have the same settings.
core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited max nice (-e) unlimited file size (blocks, -f) unlimited pending signals (-i) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) unlimited max rt priority (-r) unlimited stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Setting stack size to unlimited didn't help either.
As for make test ... was the "exception" test the problem?
Ciao, Marcus
Yes
Almost every dll test fails somehow kernel32 for example:
../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so change.c && touch change.ok err:seh:setup_exception nested exception on signal stack in thread 0010 eip 40000440 esp 7ffdbc80 stack (nil)-0xffffffff change.c:80: Test failed: Missed notification err:seh:setup_exception nested exception on signal stack in thread 0015 eip 40000440 esp 7ffd9c80 stack (nil)-0xffffffff change.c:80: Test failed: Missed notification make: *** [change.ok] Fehler 2
I also setted /proc/sys/vm/legacy_va_layout to 0|1. But no effect.
Markus
Hi!
Marcus Meissner wrote:
On Wed, Oct 11, 2006 at 11:32:47AM +0200, Markus Amsler wrote:
Hi,
What kernel version/distro are you using? What about make test.
I had similar strange behavior with 2.6.18 (debian/unstable linux-image-2.6.18-1-686): wine segfaults in multiple situations. The strangest was: make test failed/segfaulted in ntdll, but running the test manually with runtest worked !?! The rest of the system was perfect stable. With 2.6.17 everything works fine.
I'm running kernels 2.6.16 - 2.6.18. Yes, the failing machine runs 2.6.18. It seems to be a really hot trace! Just now I cannot make test, because I'm not locally on the failing machine. Will try it ASAP.
I found some reports on the net having similar problems with 2.6.18. It looks like a memory layout issue.
I did cat /proc/self/maps several times. It looks very similar on both 2.6.17 as well as 2.6.18. However, it may be something not visible there. patrol@tangens:~$ cat /proc/self/maps 0017e000-0017f000 r-xp 0017e000 00:00 0 [vdso] 0092b000-00947000 r-xp 00000000 08:01 98122 /lib/ld-2.5.so 00947000-00948000 r-xp 0001b000 08:01 98122 /lib/ld-2.5.so 00948000-00949000 rwxp 0001c000 08:01 98122 /lib/ld-2.5.so 00d8b000-00ebd000 r-xp 00000000 08:01 98151 /lib/libc-2.5.so 00ebd000-00ebf000 r-xp 00131000 08:01 98151 /lib/libc-2.5.so 00ebf000-00ec0000 rwxp 00133000 08:01 98151 /lib/libc-2.5.so 00ec0000-00ec3000 rwxp 00ec0000 00:00 0 08048000-0804c000 r-xp 00000000 08:01 32711 /bin/cat 0804c000-0804d000 rw-p 00003000 08:01 32711 /bin/cat 0972f000-09750000 rw-p 0972f000 00:00 0 b7d03000-b7d0a000 r--p 011c7000 08:01 53695 /usr/share/locale/locale-archive b7d0a000-b7d3e000 r--p 0118e000 08:01 53695 /usr/share/locale/locale-archive b7d3e000-b7f3e000 r--p 00000000 08:01 53695 /usr/share/locale/locale-archive b7f3e000-b7f40000 rw-p b7f3e000 00:00 0 bfbdf000-bfbf5000 rw-p bfbdf000 00:00 0 [stack] The kernel is patched with exec-shield, but wine works perfectly with it on 2.6.17.
Is there a ulimit set? (ulimit -a) But I think we solved this specific problem already.
All the machines have identical ulimit. Increasing values on the failing one doesn't help.
I also setted /proc/sys/vm/legacy_va_layout to 0|1. But no effect.
I did the same, also with no effect. I also tried to disable exec-shield, to be sure, and it also didn't help. Pavel