Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
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 <deo AT logos-m DOT ru>
X-Mailer:	The Bat! (v1.45) Personal
Reply-To:	egor duda <cygwin AT cygwin DOT com>
Organization:	deo
X-Priority:	3 (Normal)
Message-ID:	<55129522403.20010531115326@logos-m.ru>
To:	"Ralf Habacker" <Ralf DOT Habacker AT saght DOT tessag DOT com>
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

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

- Raw text -