Re: named pipes problem?

[Mike Hearn]

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