Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Date: Thu, 31 May 2001 11:53:26 +0400 From: egor duda X-Mailer: The Bat! (v1.45) Personal Reply-To: egor duda Organization: deo X-Priority: 3 (Normal) Message-ID: <55129522403.20010531115326@logos-m.ru> To: "Ralf Habacker" CC: cygwin AT cygwin DOT com Subject: Re: UNIX-socket problems under cygwin 1.3.2 In-reply-To: <000001c0e8ce$2f8eab40$6e032bb7@BRAMSCHE> References: <000001c0e8ce$2f8eab40$6e032bb7 AT BRAMSCHE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Wednesday, 30 May, 2001 Ralf Habacker Ralf DOT Habacker AT saght DOT tessag DOT com wrote: >>> I have figured out another problem on cygwin 1.3.2. On ported >>> kde 1.1.2 unix sockets doesn't work right. The function accept() returns an >>> error. Starting this application under cygwin 1.1.8-2 it works. Starting the >>> app with strace or gdb works. >> >> if you'd be more specific of what error accept() returns, or tell when >> it returns an error -- when called, or on incoming connection, or even >> (gasp) provide a testcase, someone surely may help. RH> I have found this RH> socket(PF_UNIX,SOCK_STREAM,0) = 5 RH> connect(5,unix_addr.sun_path=/tmp//kfm_1002_1068BRAMSCHE_0.0,size)=okay RH> ... RH> later RH> .... RH> newsock = accept (sock, (struct sockaddr *) &clientname, &size)) RH> Error accepting (UNIX) sock = 5 new_sock=-1 errno=113 it's still not clear what's going on from this description. did you connect() and accept() on the same socket, or they're totally unrelated? is the socket /tmp//kfm_1002_1068BRAMSCHE_0.0 you're connecting to being listened, or it's non-blocking socket. RH> It is curious, that if starting this app (kpanel) like below, no errors RH> occurres. RH> strace kpanel >/dev/null RH> It seems to me, that there are some correlations between strace printing RH> code and functionality of some cygwin_accept() sub functions. Perhaps some RH> statements are only executed while stracing. no. the only difference between straced and non-straced runs is timing. you can reduce strace-induced delays by supplying '-b 65535' option to strace. this turns on output buffering. RH> If you need some additional informations tell me and I will look. the most helpful thing (besides patch, of course) is a small independent code snippet that allows reproducing the problem. Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19 -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple