whee! another glibc mystery...
greg@bad-penguin wine_bld_nat $ wine Segmentation fault greg@bad-penguin wine_bld_nat $ strace wine [[ snip ]] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4035e000 mprotect(0x4002e000, 729088, PROT_READ|PROT_WRITE) = 0 mprotect(0x4002e000, 729088, PROT_READ|PROT_EXEC) = 0 set_thread_area({entry_number:-1 -> 6, base_addr:0x4035e980, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 munmap(0x40017000, 93917) = 0 brk(0) = 0x3c002000 brk(0x3c003000) = 0x3c003000 set_thread_area({entry_number:-1 -> 7, base_addr:00000000, limit:0, seg_32bit:0, contents:0, read_exec_only:1, limit_in_pages:0, seg_not_present:1, useable:0}) = 0 set_thread_area({entry_number:7, base_addr:0x400fee60, limit:4095, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:0, seg_not_present:0, useable:0}) = 0 open("/opt/wine/lib/wine/ntdll.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"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=4166825, ...}) = 0 close(3) = 0 open("/opt/wine/lib/wine/kernel32.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\0000\2"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=3495695, ...}) = 0 mmap2(NULL, 949024, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4035f000 mprotect(0x4042f000, 97056, PROT_NONE) = 0 mmap2(0x4042f000, 98304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xd0) = 0x4042f000 close(3) = 0 mprotect(0x4035f000, 851968, PROT_READ|PROT_WRITE) = 0 mprotect(0x4035f000, 851968, PROT_READ|PROT_EXEC) = 0 mprotect(0x40227000, 5, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x40227000, 5, PROT_READ|PROT_EXEC) = 0 mprotect(0x402f7000, 5, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x402f7000, 5, PROT_READ|PROT_EXEC) = 0 mprotect(0x402f4000, 5, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 mprotect(0x402f4000, 5, PROT_READ|PROT_EXEC) = 0 getcwd("/home/greg/src/wine/wine_bld_nat", 512) = 33 getuid32() = 1000 socket(PF_UNIX, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory) close(3) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ greg@bad-penguin wine_bld_nat $ gdb /opt/wine/bin/wine GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) run Starting program: /opt/wine/bin/wine
Program received signal SIGSEGV, Segmentation fault. 0x4000bba7 in _dl_init_internal () from /lib/ld-linux.so.2 (gdb) bt #0 0x4000bba7 in _dl_init_internal () from /lib/ld-linux.so.2 #1 0x4027fdd0 in _IO_link_in_internal () from /lib/libc.so.6 #2 0x4027d546 in _IO_new_file_init () from /lib/libc.so.6 #3 0x40272d94 in __fopen_internal () from /lib/libc.so.6 #4 0x40272e0e in fopen@@GLIBC_2.1 () from /lib/libc.so.6 #5 0x402f5786 in nss_parse_file () from /lib/libc.so.6 #6 0x402f52a3 in __nss_database_lookup () from /lib/libc.so.6 #7 0x402f6f95 in __nss_passwd_lookup () from /lib/libc.so.6 #8 0x402b91cf in getpwuid_r@@GLIBC_2.1.2 () from /lib/libc.so.6 #9 0x402b8ad8 in getpwuid () from /lib/libc.so.6 #10 0x40109a10 in init_paths () at ../../../wine/libs/wine/config.c:112 #11 0x40109e25 in wine_get_server_dir () at ../../../wine/libs/wine/config.c:193 #12 0x4009ce8a in CLIENT_InitServer () at ../../../wine/scheduler/client.c:641 #13 0x4009e3f6 in process_init (argv=0xbffff444) at ../../../wine/scheduler/process.c:306 #14 0x4009ea28 in __wine_process_init (argc=1, argv=0xbffff444) at ../../../wine/scheduler/process.c:480 #15 0x4010bb99 in wine_init (argc=1, argv=0xbffff444, error=0xbfffeff4 "", error_size=1024) at ../../../wine/libs/wine/loader.c:428 #16 0x3c000540 in main (argc=1, argv=0xbffff444) at ../../wine/miscemu/main.c:33 #17 0x4022748e in __libc_start_main () from /lib/libc.so.6 (gdb) up #1 0x4027fdd0 in _IO_link_in_internal () from /lib/libc.so.6 (gdb) #2 0x4027d546 in _IO_new_file_init () from /lib/libc.so.6 (gdb) #3 0x40272d94 in __fopen_internal () from /lib/libc.so.6 (gdb) #4 0x40272e0e in fopen@@GLIBC_2.1 () from /lib/libc.so.6 (gdb) #5 0x402f5786 in nss_parse_file () from /lib/libc.so.6 (gdb) #6 0x402f52a3 in __nss_database_lookup () from /lib/libc.so.6 (gdb) #7 0x402f6f95 in __nss_passwd_lookup () from /lib/libc.so.6 (gdb) #8 0x402b91cf in getpwuid_r@@GLIBC_2.1.2 () from /lib/libc.so.6 (gdb) #9 0x402b8ad8 in getpwuid () from /lib/libc.so.6 (gdb) #10 0x40109a10 in init_paths () at ../../../wine/libs/wine/config.c:112 112 struct passwd *pwd = getpwuid( getuid() ); (gdb) list 100 95 { 96 int len = strlen( path ); 97 while (len > 1 && path[len-1] == '/') path[--len] = 0; 98 } 99 100 /* initialize all the paths values */ 101 static void init_paths(void) 102 { 103 struct stat st; 104 char *p; (gdb) list 105 106 const char *home = getenv( "HOME" ); 107 const char *user = NULL; 108 const char *prefix = getenv( "WINEPREFIX" ); 109 110 #ifdef HAVE_GETPWUID 111 char uid_str[32]; 112 struct passwd *pwd = getpwuid( getuid() ); 113 114 if (pwd) (gdb) 115 { 116 user = pwd->pw_name; 117 if (!home) home = pwd->pw_dir; 118 } 119 if (!user) 120 { 121 sprintf( uid_str, "%d", getuid() ); 122 user = uid_str; 123 } 124 #else /* HAVE_GETPWUID */ (gdb) q The program is running. Exit anyway? (y or n) y
WTH is going on? Any ideas? I thought it might be my ati binary graphics drivers, (although this was never a problem before), so I put them in "wine TLS compatibility mode", or whatever, but no change.
Maybe something with my new 260-test4 kernel?
Running a simple test program which does getpwuid( getuid() ) works fine.
I do not buy, in the final analysis, that this is anything to do with nss or nscd (which I don't even run, although running it doesn't fix anything)... in fact I have a wierd suspicion that it really has to do with the server socket thingy in /tmp/.wine-greg/...
creepy, and frustrating... but disturbingly, kind of fun :) As usual, it's probably my fault, moronic and totally avoidable.
On Sun, 2003-09-07 at 23:14, Gregory M. Turner wrote:
whee! another glibc mystery...
If so, why don't you say which glibc version you use and whether you upgraded recently?
I assume a full rebuild (make clean) doesn't fix it?
I do not buy, in the final analysis, that this is anything to do with nss or nscd (which I don't even run, although running it doesn't fix anything)...
Don't let the names fool you, these read local /etc/passwd and /etc/resolv.conf files when there's no such server configured. And getpwuid() sounds suspiciously like something that would read /etc/passwd. I've heard there's been some binary incompatibility in this area of glibc lately (not with applications, but between glibc and the nss modules (used to access /etc/passwd), so that services would have to restarted after upgrading glibc, and programs statically linked with an "old" glibc wouldn't work, with win4lin being a casualty of this).
On Sunday 07 September 2003 06:16 pm, Ove Kaaven wrote:
On Sun, 2003-09-07 at 23:14, Gregory M. Turner wrote:
whee! another glibc mystery...
If so, why don't you say which glibc version you use and whether you upgraded recently?
good point. It's gentoo 2.3.2-r1, with the nptl USE flag set. I did rebuild it relatively recently, and again today just to see if it magically fixed itself (no dice)... but wine was OK sometime between those two builds, which would seem to indicate some external cause.
I assume a full rebuild (make clean) doesn't fix it?
'fraid not, I even tried a clean out-of-source build from nothing.
I do not buy, in the final analysis, that this is anything to do with nss or nscd (which I don't even run, although running it doesn't fix anything)...
Don't let the names fool you, these read local /etc/passwd and /etc/resolv.conf files when there's no such server configured. And getpwuid() sounds suspiciously like something that would read /etc/passwd.
Indeed, strace shows them being read....
I've heard there's been some binary incompatibility in this area of glibc lately (not with applications, but between glibc and the nss modules (used to access /etc/passwd), so that services would have to restarted after upgrading glibc, and programs statically linked with an "old" glibc wouldn't work, with win4lin being a casualty of this).
well since everything is from source on my box (except army ops :)) that shouldn't be my problem... the nss libs are part of the glibc ebuild, so it really all ought be in sync....
maybe it's time for me to rebuild glibc with debug symbols... I still suspect that the root cause is some incredibly trivial act of systems-administrative stupidity on my part :(
thanks for your help,
-
Gregory M. Turner -
Ove Kaaven