Hi list,
I have just performed an upgrade to my Debian Sid Linux. During the upgrade, libc was replaced. I can now not get Wine to work on the new install.
Previously, I would use Wine without --with-nptl. This no longer works. Wine sigsegv on startup (whether there are parameters or not).
compiling with --with-nptl gets me slightly further. Running wine without parameters produces the help printout. However, when I try to actually run something, this does not work. It doesn't matter what I try to run (whether winelib or Windows). I get a series of "unhandled expection". This happens even for the regedit that is supposed to install my default registry via tools/wineinstall
Any ideas? Anyone?
Shachar Shemesh wrote:
Hi list,
I have just performed an upgrade to my Debian Sid Linux. During the upgrade, libc was replaced. I can now not get Wine to work on the new install.
Previously, I would use Wine without --with-nptl. This no longer works. Wine sigsegv on startup (whether there are parameters or not).
compiling with --with-nptl gets me slightly further. Running wine without parameters produces the help printout. However, when I try to actually run something, this does not work. It doesn't matter what I try to run (whether winelib or Windows). I get a series of "unhandled expection". This happens even for the regedit that is supposed to install my default registry via tools/wineinstall
Any ideas? Anyone?
As Juraj sent his message almost simultaniously with mine, I just wanted to make it clear that my problem was not the same. It appears that some black magic is destroying the content of a variable between calls.
In "DOSFS_OpenDir", there is a variable "unix_path". At one point (pretty early, but not at the first time), this is set to my home directory ("/home/sun"). The function then calls "DOSFS_OpenDir_Normal". Instead of getting "/home/sun", however, DOSFS_OpenDir_Normal gets NULL. It calls "opendir" with NULL, and sigsegv is happening.
I am currently trying to compile Wine without optimizations, to see whether I have triggered some wierd compiler bug. I somewhat doubt this, however, as the several first iterations succeed without a problem.
I'm investigating this further, but if anyone has any idea.....
Shachar
On Wed, 10 Sep 2003 16:03:23 +0300, you wrote:
Hi list,
I have just performed an upgrade to my Debian Sid Linux. During the upgrade, libc was replaced. I can now not get Wine to work on the new install.
ACK. I have downgraded to glibc-2.3.2-5 and it works again.
strace wine:
| execve("/usr/local/bin/wine", ["wine"], [/* 27 vars */]) = 0 | uname({sys="Linux", node="sumba.wallam", ...}) = 0 | brk(0) = 0x3c00180c | old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 | open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) | open("/etc/ld.so.cache", O_RDONLY) = 3 | fstat64(3, {st_mode=S_IFREG|0644, st_size=88549, ...}) = 0 | old_mmap(NULL, 88549, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000 | close(3) = 0 | open("/usr/local/lib/libntdll.dll.so", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\360\1"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0755, st_size=4181929, ...}) = 0 | old_mmap(NULL, 882856, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002c000 | old_mmap(0x400dc000, 45056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xb0000) = 0x400dc000 | old_mmap(0x400e7000, 116904, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400e7000 | close(3) = 0 | open("/usr/local/lib/libwine.so.1", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\26"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0755, st_size=241816, ...}) = 0 | old_mmap(NULL, 96000, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40104000 | old_mmap(0x40109000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x4000) = 0x40109000 | old_mmap(0x4010a000, 71424, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4010a000 | close(3) = 0 | open("/usr/local/lib/libwine_unicode.so.1", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\34"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0755, st_size=1272081, ...}) = 0 | old_mmap(NULL, 989584, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4011c000 | old_mmap(0x4020d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xf1000) = 0x4020d000 | close(3) = 0 | open("/lib/libc.so.6", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p^\1\000"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0755, st_size=1230864, ...}) = 0 | old_mmap(NULL, 1236292, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4020e000 | old_mmap(0x40335000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127000) = 0x40335000 | old_mmap(0x4033a000, 7492, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4033a000 | close(3) = 0 | open("/lib/libm.so.6", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 5\0\000"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0644, st_size=135604, ...}) = 0 | old_mmap(NULL, 138160, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4033c000 | old_mmap(0x4035d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x20000) = 0x4035d000 | close(3) = 0 | open("/lib/libdl.so.2", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \34\0\000"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0644, st_size=9796, ...}) = 0 | old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4035e000 | old_mmap(NULL, 8632, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4035f000 | old_mmap(0x40361000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0x40361000 | close(3) = 0 | mprotect(0x4002c000, 720896, PROT_READ|PROT_WRITE) = 0 | mprotect(0x4002c000, 720896, PROT_READ|PROT_EXEC) = 0 | munmap(0x40016000, 88549) = 0 | brk(0) = 0x3c00180c | brk(0x3c02280c) = 0x3c02280c | brk(0x3c023000) = 0x3c023000 | --- SIGSEGV (Segmentation fault) @ 0 (0) --- | +++ killed by SIGSEGV +++
gdb:
| Program received signal SIGSEGV, Segmentation fault. | 0x4026b32e in mallopt () from /lib/libc.so.6 | (gdb) bt | #0 0x4026b32e in mallopt () from /lib/libc.so.6 | #1 0x4026a543 in malloc () from /lib/libc.so.6 | #2 0x40005c5b in _dl_map_object_internal () from /lib/ld-linux.so.2 | #3 0x402ff88b in getutmpx () from /lib/libc.so.6
From the changelist of glibc-2.3.2-6 there seems to be only one
applicable item:
| - debian/patches/pthread_cond_timedwait.dpatch: avoid problem when | pthread_cond_timedwait is used in code that doesn't link with | -lpthread. (Closes: #209139)
Not that I understand that at all. Comments are welcome.
Previously, I would use Wine without --with-nptl. This no longer works. Wine sigsegv on startup (whether there are parameters or not).
My understanding was that you need an nptl enabled kernel (2.6x) for this so I did not try. But I may very well be wrong.
Rein.
Rein Klazes wrote:
On Wed, 10 Sep 2003 16:03:23 +0300, you wrote:
Hi list,
I have just performed an upgrade to my Debian Sid Linux. During the upgrade, libc was replaced. I can now not get Wine to work on the new install.
ACK. I have downgraded to glibc-2.3.2-5 and it works again.
Can you tell me what command you used to do that? When I tried what I understood would do that, it was about to uninstall most of my system, including some critical stuff.
I tired, IIRC, "apt-get install libc6=2.2.5-11.2".
Hmm, ok, I'll rephrase the question - where can I find the 2.3.2-5 deb?
Shachar
strace wine:
| execve("/usr/local/bin/wine", ["wine"], [/* 27 vars */]) = 0 | uname({sys="Linux", node="sumba.wallam", ...}) = 0 | brk(0) = 0x3c00180c | old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 | open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) | open("/etc/ld.so.cache", O_RDONLY) = 3 | fstat64(3, {st_mode=S_IFREG|0644, st_size=88549, ...}) = 0 | old_mmap(NULL, 88549, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000 | close(3) = 0 | open("/usr/local/lib/libntdll.dll.so", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\360\1"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0755, st_size=4181929, ...}) = 0 | old_mmap(NULL, 882856, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002c000 | old_mmap(0x400dc000, 45056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xb0000) = 0x400dc000 | old_mmap(0x400e7000, 116904, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400e7000 | close(3) = 0 | open("/usr/local/lib/libwine.so.1", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\26"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0755, st_size=241816, ...}) = 0 | old_mmap(NULL, 96000, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40104000 | old_mmap(0x40109000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x4000) = 0x40109000 | old_mmap(0x4010a000, 71424, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4010a000 | close(3) = 0 | open("/usr/local/lib/libwine_unicode.so.1", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\34"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0755, st_size=1272081, ...}) = 0 | old_mmap(NULL, 989584, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4011c000 | old_mmap(0x4020d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xf1000) = 0x4020d000 | close(3) = 0 | open("/lib/libc.so.6", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p^\1\000"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0755, st_size=1230864, ...}) = 0 | old_mmap(NULL, 1236292, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4020e000 | old_mmap(0x40335000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x127000) = 0x40335000 | old_mmap(0x4033a000, 7492, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4033a000 | close(3) = 0 | open("/lib/libm.so.6", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 5\0\000"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0644, st_size=135604, ...}) = 0 | old_mmap(NULL, 138160, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4033c000 | old_mmap(0x4035d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x20000) = 0x4035d000 | close(3) = 0 | open("/lib/libdl.so.2", O_RDONLY) = 3 | read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \34\0\000"..., 512) = 512 | fstat64(3, {st_mode=S_IFREG|0644, st_size=9796, ...}) = 0 | old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4035e000 | old_mmap(NULL, 8632, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4035f000 | old_mmap(0x40361000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0x40361000 | close(3) = 0 | mprotect(0x4002c000, 720896, PROT_READ|PROT_WRITE) = 0 | mprotect(0x4002c000, 720896, PROT_READ|PROT_EXEC) = 0 | munmap(0x40016000, 88549) = 0 | brk(0) = 0x3c00180c | brk(0x3c02280c) = 0x3c02280c | brk(0x3c023000) = 0x3c023000 | --- SIGSEGV (Segmentation fault) @ 0 (0) --- | +++ killed by SIGSEGV +++
gdb:
| Program received signal SIGSEGV, Segmentation fault. | 0x4026b32e in mallopt () from /lib/libc.so.6 | (gdb) bt | #0 0x4026b32e in mallopt () from /lib/libc.so.6 | #1 0x4026a543 in malloc () from /lib/libc.so.6 | #2 0x40005c5b in _dl_map_object_internal () from /lib/ld-linux.so.2 | #3 0x402ff88b in getutmpx () from /lib/libc.so.6
From the changelist of glibc-2.3.2-6 there seems to be only one applicable item:
| - debian/patches/pthread_cond_timedwait.dpatch: avoid problem when | pthread_cond_timedwait is used in code that doesn't link with | -lpthread. (Closes: #209139)
Not that I understand that at all. Comments are welcome.
Previously, I would use Wine without --with-nptl. This no longer works. Wine sigsegv on startup (whether there are parameters or not).
My understanding was that you need an nptl enabled kernel (2.6x) for this so I did not try. But I may very well be wrong.
Rein.
On Wed, 10 Sep 2003 18:39:51 +0300, you wrote:
Rein Klazes wrote:
On Wed, 10 Sep 2003 16:03:23 +0300, you wrote:
Hi list,
I have just performed an upgrade to my Debian Sid Linux. During the upgrade, libc was replaced. I can now not get Wine to work on the new install.
ACK. I have downgraded to glibc-2.3.2-5 and it works again.
Can you tell me what command you used to do that? When I tried what I understood would do that, it was about to uninstall most of my system, including some critical stuff.
I tired, IIRC, "apt-get install libc6=2.2.5-11.2".
Hmm, ok, I'll rephrase the question - where can I find the 2.3.2-5 deb?
Shachar
If they are not still on your system (/var/cache/apt/archives/) you can download them from a local Debian mirror in pool/main/g/glibc.
Then I did
| dpkg -i libc6-dev_2.3.2-5_i386.deb libc6_2.3.2-5_i386.deb locales_2.3.2-5_all.deb
Rein.
Rein Klazes wrote:
If they are not still on your system (/var/cache/apt/archives/)
Luckily - it was, indeed, there. Thanks.
you can download them from a local Debian mirror in pool/main/g/glibc.
Yes, on second inspection there were ther. Then again, apt-get install libc6=2.3.2-5 didn't work. Must belong to "Stable"...
Then I did
| dpkg -i libc6-dev_2.3.2-5_i386.deb libc6_2.3.2-5_i386.deb locales_2.3.2-5_all.deb
Rein.
Thanks. It got my wine back to life too.
Shachar
On Wed, Sep 10, 2003 at 08:44:57PM +0300, Shachar Shemesh wrote:
Rein Klazes wrote:
If they are not still on your system (/var/cache/apt/archives/)
Luckily - it was, indeed, there. Thanks.
you can download them from a local Debian mirror in pool/main/g/glibc.
Yes, on second inspection there were ther. Then again, apt-get install libc6=2.3.2-5 didn't work. Must belong to "Stable"...
The newest glibc snapshot causes problems somewhere in pthread_cond_wait or similar. Our glibc guru is on it ;) --with-nptl helps though.
Ciao, Marcus
Marcus Meissner wrote:
On Wed, Sep 10, 2003 at 08:44:57PM +0300, Shachar Shemesh wrote:
Rein Klazes wrote:
If they are not still on your system (/var/cache/apt/archives/)
Luckily - it was, indeed, there. Thanks.
you can download them from a local Debian mirror in pool/main/g/glibc.
Yes, on second inspection there were ther. Then again, apt-get install libc6=2.3.2-5 didn't work. Must belong to "Stable"...
The newest glibc snapshot causes problems somewhere in pthread_cond_wait or similar. Our glibc guru is on it ;) --with-nptl helps though.
Ciao, Marcus
Welllll. It helps in that with it you can get the wine command line string. You still can't actually run anything. (at least, not that I found out how).
Shachar
On Wed, 2003-09-10 at 17:31, Rein Klazes wrote:
From the changelist of glibc-2.3.2-6 there seems to be only one
applicable item:
| - debian/patches/pthread_cond_timedwait.dpatch: avoid problem when | pthread_cond_timedwait is used in code that doesn't link with | -lpthread. (Closes: #209139)
Not that I understand that at all. Comments are welcome.
I've just got a bug report on it (#210300) so I've taken a look. So, this pthread_cond_timedwait.dpatch contains:
--- libc/linuxthreads/sysdeps/pthread/pthread-functions.h.jj 2003-04-20 03:37:06.000000000 -0400 +++ libc/linuxthreads/sysdeps/pthread/pthread-functions.h 2003-09-01 05:35:34.000000000 -0400 @@ -54,6 +54,8 @@ struct pthread_functions const pthread_condattr_t *); int (*ptr___pthread_cond_signal) (pthread_cond_t *); int (*ptr___pthread_cond_wait) (pthread_cond_t *, pthread_mutex_t *); + int (*ptr___pthread_cond_timedwait) (pthread_cond_t *, pthread_mutex_t *, + const struct timespec *); int (*ptr_pthread_equal) (pthread_t, pthread_t); void (*ptr___pthread_exit) (void *); int (*ptr_pthread_getschedparam) (pthread_t, int *, struct sched_param *);
Compare with Wine's scheduler/pthread.c:
struct pthread_functions { ... int (*ptr___pthread_cond_init) (pthread_cond_t *, const pthread_condattr_t *); int (*ptr___pthread_cond_signal) (pthread_cond_t *); int (*ptr___pthread_cond_wait) (pthread_cond_t *, pthread_mutex_t *); int (*ptr_pthread_equal) (pthread_t, pthread_t); void (*ptr___pthread_exit) (void *); int (*ptr_pthread_getschedparam) (pthread_t, int *, struct sched_param *); ... };
See the problem?
Hmm, now should I complain to Debian's glibc maintainers, or is this Wine's problem?
Ove Kaaven ovehk@ping.uio.no writes:
See the problem?
Hmm, now should I complain to Debian's glibc maintainers, or is this Wine's problem?
In a sense it's a Wine problem, since this is an internal structure we are not really supposed to be using. However, I don't think there's any way we can fix the problem on our side, so we are going to need a change in glibc (moving the new function to the end of the structure should work).
On Wed, 2003-09-10 at 22:10, Alexandre Julliard wrote:
Ove Kaaven ovehk@ping.uio.no writes:
See the problem?
Hmm, now should I complain to Debian's glibc maintainers, or is this Wine's problem?
In a sense it's a Wine problem, since this is an internal structure we are not really supposed to be using. However, I don't think there's any way we can fix the problem on our side, so we are going to need a change in glibc (moving the new function to the end of the structure should work).
OK, bug #210347 has been filed against the Debian libc6 package.
Ove Kaaven ovehk@ping.uio.no writes:
OK, bug #210347 has been filed against the Debian libc6 package.
The glibc guys have been kind enough to make the change, so this is fixed in the current glibc CVS (and I put in the corresponding change on the Wine side).
-
Alexandre Julliard -
Marcus Meissner -
Ove Kaaven -
Rein Klazes -
Shachar Shemesh