This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Info on "Can't open display"



> You will lose fork() support for sockets if you use winsock32 directly.


I know.  What I want to see if this display problem goes away with it.
I know it is not the best way.

> I'm much more keen on identifying why the problem occurs - we can
> probably solve it quickly inside cygwin1.dll once we know that.

Can anyone build a debug version of Cygwin1.dll with the Egor Duda patch he
posted this morning?  I do not have time to fool around with Cygwin code.

Suhaib

Hi!

Friday, 15 June, 2001 Ralf Habacker Ralf.Habacker@saght.tessag.com wrote:

>> > The only change we had in the accept() code between 1.1.8 and 1.3.2 
>> > was Egor's patch to support secure connections on AF_UNIX sockets. 
>> > Is it possible that the security check fails under some 
>> > circumstances here?

you can apply this to cygwin sources, rebuild cygwin1.dll and see if it
helps. this disables security checks i've added to AF_UNIX socket code. if
it helps, then there may be some problem with my code.

Index: net.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/net.cc,v
retrieving revision 1.57
diff -u -p -1 -r1.57 net.cc
--- net.cc      2001/06/03 22:18:19     1.57
+++ net.cc      2001/06/15 09:27:01
@@ -765,2 +765,3 @@ cygwin_connect (int fd,
         }
+#if 0
       if (sock->get_addr_family () == AF_UNIX)
@@ -793,2 +794,3 @@ cygwin_connect (int fd,
         }
+#endif
     }
@@ -902,3 +904,3 @@ cygwin_accept (int fd, struct sockaddr *
       res = accept (sock->get_socket (), peer, len);  // can't use a
blocking call inside a lock
-
+#if 0
       if (sock->get_addr_family () == AF_UNIX)
@@ -934,3 +936,3 @@ cygwin_accept (int fd, struct sockaddr *
         }
-
+#endif
       SetResourceLock (LOCK_FD_LIST, WRITE_LOCK|READ_LOCK, "accept");

RH> I will try, but the difficulty is that on stracing the error does 
RH> not occure. I will analyze it in more detail ...

RH> an example

[...]

RH> Done anyone have an idea ?

unfortunately, i don't have kde installed so i can't get any meaningful
explanation of all those debug outputs. i suspect, however, that this
accept()-involved code could be somehow reduced to small testcase.

you have already sent some bits to cygwin mailing list, and, if i understand
them correctly, it has some weird sequences of calls such as 'conenect() to
socket and then accept() on it without closing it beforehand'. is that so?
if you'll be able to extract socket-related code that fails into reasonably
small and self-contained program, i'll be able to debug it.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19

> 
> Rob
> 
> >
> > > for local connections. Cygwin1.dll emulates such sockets using
> normal
> > > win32 sockets and a file on disk. If thats the case any win32 only
> > > program is not a valid example of a working tool. What would be a
> valid
> > > comparison is a test client-server package that use AF_UNIX
> sockets -
> > > say CORBA based or something similar.
> >
> >


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]