Does everybody's kernel32 named pipes test pass (in wine)? Named pipes are acting very wierd here, lots of segfaults and other wierdness... the test seems to freeze attempting to create the alarmThread in test_NamedPipe_2 (test 3 of 4). The wineserver holds up OK, but the client side looks a mess.
This is similar to other behavior I see in other contexts... perhaps, the pattern is, after I create a named pipe, subsequent calls to CreateThread never return or cause segfaults and general instability.
Am I the only one? The following is a snippet from "strace -f wine kernel32_test.exe.so pipe" where wine starts to go south....
[pid 28568] write(1, "pipe.c:459:", 11pipe.c:459:) = 11 [pid 28568] write(1, "exercizeServer starting\n", 24exercizeServer starting ) = 24 [pid 28568] write(1, "pipe.c:470:", 11pipe.c:470:) = 11 [pid 28568] write(1, "Client connecting...\n", 21Client connecting... ) = 21 [pid 28568] rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 [pid 28568] writev(4, [{"\207\0\0\0\222\0\0\0\0\0\0\0\0\0\0\300\0\0\0\0\0\0\0\0"..., 64}, {"\\0\\0.\0\\0P\0i\0P\0e\0\\0t\0e\0s\0t\0s\0_\0.\0"..., 146}], 2 <unfinished ...> [pid 28570] <... poll resumed> [{fd=5, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN, revents=POLLIN}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=24, events=POLLIN}, {fd=23, events=POLLIN}], 16, -1) = 1 [pid 28570] read(16, "\207\0\0\0\222\0\0\0\0\0\0\0\0\0\0\300\0\0\0\0\0\0\0\0"..., 64) = 64 [pid 28570] read(16, "\\0\\0.\0\\0P\0i\0P\0e\0\\0t\0e\0s\0t\0s\0_\0.\0"..., 146) = 146 [pid 28570] write(17, "\17\0\0\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 [pid 28570] poll( <unfinished ...> [pid 28568] <... writev resumed> ) = 210 [pid 28568] read(5, "\17\0\0\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 [pid 28568] rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 [pid 28568] write(1, "pipe.c:481:", 11pipe.c:481:) = 11 [pid 28568] write(1, "connect failed, retrying\n", 25connect failed, retrying ) = 25 [pid 28568] gettimeofday({1066424342, 296207}, NULL) = 0 [pid 28568] gettimeofday({1066424342, 296363}, NULL) = 0 [pid 28568] select(0, NULL, NULL, NULL, {0, 199844} <unfinished ...> [pid 28575] --- SIGSTOP (Stopped (signal)) @ 0 (0) --- [pid 28574] --- SIGSTOP (Stopped (signal)) @ 0 (0) --- [pid 28575] modify_ldt(17, {entry_number:40, base_addr:0x40af3000, limit:4095, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:0, seg_not_present:0, useable:0}, 16 <unfinished ...> [pid 28574] modify_ldt(17, {entry_number:39, base_addr:0x408c3000, limit:4095, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:0, seg_not_present:0, useable:0}, 16 <unfinished ...> [pid 28575] <... modify_ldt resumed> ) = 0 [pid 28574] <... modify_ldt resumed> ) = 0 [pid 28575] sigaltstack({ss_sp=0x408d1000, ss_flags=0, ss_size=1048576} <unfinished ...> [pid 28574] brk(0 <unfinished ...> [pid 28575] <... sigaltstack resumed> , NULL) = 0 [pid 28574] <... brk resumed> ) = 0x3c009000 [pid 28575] rt_sigaction(SIGINT, {0x40081bf2, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28574] brk(0x3c00a000 <unfinished ...> [pid 28575] <... rt_sigaction resumed> NULL, 8) = 0 [pid 28574] <... brk resumed> ) = 0x3c00a000 [pid 28575] rt_sigaction(SIGFPE, {0x40081b76, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28574] sigaltstack({ss_sp=0x406a1000, ss_flags=0, ss_size=1048576} <unfinished ...> [pid 28575] <... rt_sigaction resumed> NULL, 8) = 0 [pid 28574] <... sigaltstack resumed> , NULL) = 0 [pid 28575] rt_sigaction(SIGSEGV, {0x40081aa4, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28574] rt_sigaction(SIGINT, {0x40081bf2, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28575] <... rt_sigaction resumed> NULL, 8) = 0 [pid 28574] <... rt_sigaction resumed> NULL, 8) = 0 [pid 28575] rt_sigaction(SIGILL, {0x40081aa4, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28574] rt_sigaction(SIGFPE, {0x40081b76, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28575] <... rt_sigaction resumed> NULL, 8) = 0 [pid 28574] <... rt_sigaction resumed> NULL, 8) = 0
from there it just degrades into a soup of SIGSEGV and rt_sigprocmask(), like:
[pid 28575] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 28574] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 28575] rt_sigprocmask(SIG_UNBLOCK, ~[], <unfinished ...> [pid 28574] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 28575] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 28574] rt_sigprocmask(SIG_UNBLOCK, ~[], <unfinished ...> [pid 28575] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 28574] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 28575] rt_sigprocmask(SIG_UNBLOCK, ~[], <unfinished ...> [pid 28574] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 28575] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 28574] rt_sigprocmask(SIG_UNBLOCK, ~[], <unfinished ...> [pid 28575] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 28574] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 28575] rt_sigprocmask(SIG_UNBLOCK, ~[], <unfinished ...>
this never ends. Attaching to various threads (when I am so lucky as to be able to) is not very instructive (to me ;)).
On Fri, 17 Oct 2003 16:20:04 -0500, Sir Gregory M. Turner scribed thus:
Does everybody's kernel32 named pipes test pass (in wine)? Named pipes are acting very wierd here, lots of segfaults and other wierdness... the test seems to freeze attempting to create the alarmThread in test_NamedPipe_2 (test 3 of 4). The wineserver holds up OK, but the client side looks a
mess.
Ditto - I'm seeing this problem now also, it's stopping me working on the DCOM stuff. A backtrace of the crash looks like this:
(gdb) bt #0 0x4012f40b in __libc_enable_asynccancel () from /lib/i686/libc.so.6 #1 0x401159b7 in fcntl () from /lib/i686/libc.so.6 #2 0x404b250d in CreateThread (sa=0x0, stack=0, start=0x4076eec0 <serverThreadMain1>, param=0x0, flags=0, id=0x409b2e30) at thread.c:196 #3 0x407702fa in test_NamedPipe_2 () at pipe.c:522 #4 0x40770728 in func_pipe () at pipe.c:597 #5 0x40778dbe in run_test (name=0xbffff9a4 "pipe") at ../../../include/wine/test.h:292 #6 0x40749038 in __wine_exe_main () at kernel32_test.exe.spec.c:812 #7 0x401d894b in LdrInitializeThunk (main_file=0x0, CreateFileW_ptr=0x40467de8, unknown3=0, unknown4=0) at loader.c:1845 #8 0x4049e4b7 in start_process (arg=0x0) at process.c:726
Here's the RPC server backtrace:
#0 0x4012f40b in __libc_enable_asynccancel () from /lib/i686/libc.so.6 #1 0x40115716 in write () from /lib/i686/libc.so.6 #2 0x401e545f in wine_server_call (req_ptr=0x4096278c) at server.c:226 #3 0x401db6ce in NtClose (Handle=0x2c) at om.c:343 #4 0x404a12a2 in CloseHandle (handle=0x2c) at process.c:2179 #5 0x407477c1 in RPCSS_BecomePipeServer () at np_server.c:526 #6 0x40747d35 in RPCSS_Initialize () at rpcss_main.c:191 #7 0x40748070 in main (argc=1, argv=0xbffff878) at rpcss_main.c:311 #8 0x40746038 in __wine_exe_main () at rpcss.exe.spec.c:176 #9 0x401d894b in LdrInitializeThunk (main_file=0x0, CreateFileW_ptr=0x40467de8, unknown3=0, unknown4=0) at loader.c:1845 #10 0x4049e4b7 in start_process (arg=0x0) at process.c:726
libc_enable_asynccancel seems to be threading related, here is the code from glibc sources:
/* The next two functions are similar to pthread_setcanceltype() but more specialized for the use in the cancelable functions like write(). They do not need to check parameters etc. */ int attribute_hidden __libc_enable_asynccancel (void) { pthread_descr self = thread_self(); int oldtype = LIBC_THREAD_GETMEM(self, p_canceltype); LIBC_THREAD_SETMEM(self, p_canceltype, PTHREAD_CANCEL_ASYNCHRONOUS); if (__builtin_expect (LIBC_THREAD_GETMEM(self, p_canceled), 0) && LIBC_THREAD_GETMEM(self, p_cancelstate) == PTHREAD_CANCEL_ENABLE) __libc_maybe_call2 (pthread_do_exit, (PTHREAD_CANCELED, CURRENT_STACK_FRAME), 0); return oldtype; }
void internal_function attribute_hidden __libc_disable_asynccancel (int oldtype) { pthread_descr self = thread_self(); LIBC_THREAD_SETMEM(self, p_canceltype, oldtype); }
Alexandre - this is your area. Any ideas?
thanks -mike
Mike Hearn mike@theoretic.com writes:
Alexandre - this is your area. Any ideas?
Your glibc is using TLS. Support for that is not ready yet. Depending on your system you need to either set LD_ASSUME_KERNEL=2.4 or install another glibc that doesn't use TLS.
On Saturday 18 October 2003 12:38 pm, Alexandre Julliard wrote:
Mike Hearn mike@theoretic.com writes:
Alexandre - this is your area. Any ideas?
Your glibc is using TLS. Support for that is not ready yet. Depending on your system you need to either set LD_ASSUME_KERNEL=2.4 or install another glibc that doesn't use TLS.
hmm... "emerge glibc" says:
../../linuxthreads/configure' '--with-gd=no' '--without-cvs' '--disable-profile' '--without-tls' '--without-__thread' '--enable-add-ons=linuxthreads' '--enable-kernel=2.4.1' '--srcdir=../../linuxthreads'
which ostensibly would seem to contradict your prognosis... (although I assume you are nevertheless correct -- this is not the root-dir configure, so maybe it's misleading me. I will poke at it again to see what gentoo is really doing next time I boot up that box).
As for LD_ASSUME_KERNEL=2.4... the result is very similar to that of "rm -rf /," or at least "rm -rf /lib /usr/lib" -- no love.
However, I do not despair. I upgraded my nptl box to nptl 0.60, gcc 3.3.1, and glibc2.3.2-branch-update-20030927, and it's running wine now, at long last. yay! Far more satisfying than running it in that nasty vm anyhow....
So, whereas before I had without-nptl wine and no with-nptl wine, now I have with-nptl wine and no without-nptl wine. *sigh* when will I learn my lesson and just run Red Hat? ;)
On Sun, 19 Oct 2003 01:00:51 -0500, Sir Gregory M. Turner scribed thus:
which ostensibly would seem to contradict your prognosis... (although I assume you are nevertheless correct -- this is not the root-dir configure, so maybe it's misleading me. I will poke at it again to see what gentoo is really doing next time I boot up that box).
Just run libc:
[mike@littlegreen downloads]$ /lib/i686/libc-2.3.2.so GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2.2 20030222 (Red Hat Linux 3.2.2-5). Compiled on a Linux 2.4.20 system on 2003-04-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy The C stubs add-on version 2.1.2. BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. <------------------------ Report bugs using the `glibcbug' script to bugs@gnu.org.
Ditto for the LD_ASSUME_KERNEL thing, it can't find libc.so, so I guess that means I don't have a compatible one installed.
On Sunday 19 October 2003 05:20 am, Mike Hearn wrote:
On Sun, 19 Oct 2003 01:00:51 -0500, Sir Gregory M. Turner scribed thus:
which ostensibly would seem to contradict your prognosis... (although I assume you are nevertheless correct -- this is not the root-dir configure, so maybe it's misleading me. I will poke at it again to see what gentoo is really doing next time I boot up that box).
Just run libc:
[mike@littlegreen downloads]$ /lib/i686/libc-2.3.2.so GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2.2 20030222 (Red Hat Linux 3.2.2-5). Compiled on a Linux 2.4.20 system on 2003-04-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy The C stubs add-on version 2.1.2. BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton libthread_db work sponsored by Alpha Processor Inc Thread-local storage support included. <------------------------ Report bugs using the `glibcbug' script to bugs@gnu.org.
cool trick. an ironic side-note (I have not tried this on my without-nptl system yet, so the following is not relevant to my problem): on my nptl system (the one that works now), I get:
# /lib/libc-2.3.2.so Inconsistency detected by ld.so: rtld.c: 1238: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!
oy! I wonder, does this indicate a real problem that I should be worried about? ...
On Mon, 2003-10-20 at 00:19, Gregory M. Turner wrote:
cool trick. an ironic side-note (I have not tried this on my without-nptl system yet, so the following is not relevant to my problem): on my nptl system (the one that works now), I get:
# /lib/libc-2.3.2.so Inconsistency detected by ld.so: rtld.c: 1238: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed!
oy! I wonder, does this indicate a real problem that I should be worried about? ...
Probably. The map list is a pretty important structure, if it has holes in it (as that assert would imply) something is going to blow up somewhere...