patrol at sinus.cz
Wed Oct 11 04:07:31 CDT 2006
> Marcus Meissner wrote:
> >On Wed, Oct 11, 2006 at 11:32:47AM +0200, Markus Amsler wrote:
> >>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
> >>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 at 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
> >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
> 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.
More information about the wine-devel