Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Content-Type: text/plain; charset="iso-8859-1" From: pullmoll AT t-online DOT de (Juergen Buchmueller) Reply-To: pullmoll AT stop1984 DOT com To: cygwin AT cygwin DOT com Subject: anon, shared mmap (was Re: _exit() missing WSACleanup() call?) Date: Tue, 6 Aug 2002 13:36:44 +0200 User-Agent: KMail/1.4.2 References: <1028578338 DOT 7433 DOT ezmlm AT cygwin DOT com> <20020806095349 DOT N3921 AT cygbert DOT vinschen DOT de> <20020806095852 DOT P3921 AT cygbert DOT vinschen DOT de> In-Reply-To: <20020806095852.P3921@cygbert.vinschen.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208061336.52661.pullmoll@stop1984.com> X-Sender: 320028791064-0001 AT t-dialin DOT net -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 06 August 2002 09:58, Corinna Vinschen wrote: > On Tue, Aug 06, 2002 at 09:53:49AM +0200, Corinna Vinschen wrote: > > Could you run `strace -f' and look if there's > > Scratch that. Obviously it could also help to run strace but I > found that I'm unable to explain what I'd like you to look for... > I think the testcase is the way to go. I'm on FreeBSD 4.6 to answer your previous question. And to give you a hint about what happens, the order of process creations and mmaps is like this: parent -> process 'store' map1 = mmap(NULL,size1,PROT_READ|PROT_WRITE,MAP_ANON|MAP_SHARED,-1,0); fork2() -> parent returns -> child creates one or more mmaps on files, MAP_SHARED too, which isn't really required as I saw now ;) Waits for entries in a queue held in map1 -> process 'peer' map2 = mmap(NULL,size2,PROT_READ|PROT_WRITE,MAP_ANON|MAP_SHARED,-1,0); fork2() -> parent returns -> child listens and accepts sockets on port A after accepting a connection fork2() -> parent returns -> child reads/writes map2 w/o problems when child writes to map1 creates a copy(****) child exits when socket is closed or error occurs fork2() -> parent returns -> child calls setitimer() and sleeps forever signal handler reads/writes map2 w/o problems, doesn't touch map1 -> process 'client' fork2() -> parent returns -> child listens and accepts sockets on port B after accepting a connection fork2() -> parent returns -> child might read/write map1 and map2, no problem found child exits when socket is closed or error occurs -> process 'proxy' fork2() -> parent returns -> child listens and accepts sockets on port C after accepting a connection fork2() -> parent returns -> child might read/write map1 and map2, no problem found child exits when socket is closed or error occurs Then the parent exits, leaving five processes of which three might create new child processes. The problem arises when the 'peer' listener creates a child that writes to map1. So it actually looks like the map1 somehow looses the PROT_WRITE attribute and instead becomes COPYWRITE for the child processes. The later created map2 doesn't show this behaviour, though it is created on the same nesting level. I have to think about a simpler test case to reproduce these happenings. It doesn't look all too easy, not even for me - despite the fact that I wrote this crap ;) > Corinna Ciao, Juergen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9T7TRtCKWJo++MqgRAs/LAKCsk1iLg/BUhusnKgi0QhKgg4tMzgCgsn6S 56cnsWLJGYp9L2QwMyg6KY8= =3TIY -----END PGP SIGNATURE----- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/