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: Re: _exit() missing WSACleanup() call? Date: Tue, 6 Aug 2002 05:44:20 +0200 User-Agent: KMail/1.4.2 References: <1028578338 DOT 7433 DOT ezmlm AT cygwin DOT com> In-Reply-To: <1028578338.7433.ezmlm@cygwin.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200208060544.29738.pullmoll@stop1984.com> X-Sender: 320028791064-0001 AT t-dialin DOT net -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 05 August 2002 22:12, corinna-cygwin AT cygwin DOT com wrote: [snip - suspected WSAStartup/Cleanup memory leak; which isn't there] > When calling WSACleanup() in your application doesn't help, it's > somewhat likely that the problem is actually in your code. What > is the parent process doing with the sockets? It is accept()ing them after listen()ing on INADDR_ANY on a certain port... The parent uses fork2() [2] to detach the child, waits for the first child to return with wait() and closes the accepted socket itself. > Is it surely closing and (perhaps) shutting them down properly? Yup, the forked child processes (and also the error cases) did do that. I now even tried to close all fds from 3 up to the system limit in my osd_exit() only to discover that it changed nothing. But the problem is elsewhere, so this is no surprise :) > Did you look for netstat output? No, but the problem is elsewhere... read on. Out of interest and due to my lack of knowledge: would inherited socket connections be listed twice or more in netstat's output? >> The same project runs fine for days on various FreeBSD and GNU/Linux >> systems. > > That's actually not good an example. The socket implementation is > *waaayyyy* cleaner in BSD and Linux than is Winsock. Sorry to have brought up a false alarm as it seems now. I didn't spend long enough with CYGWIN to closely inspect the cause of my problems. It actually seems to be the mmap() implementation which is giving me troubles. After looking through the winsup/cygwin/mmap.cc code and reading the comments there, I even think I better stick up trying to port my crap to Windows ;-) Here's what I suspect now after narrowing down the problem and taking a close look at the Windows utility to visualize your system resources [1]: I have two mmap()ed memory regions with MAP_ANON|MAP_SHARED and protection PROT_READ|PROT_WRITE. Both are created by the parent process which is actually only a startup process, since it leaves several fork2() [2] children running and exits itself. You could say it is a daemon -- or tries to be one. Now the first mmap() region seems to work fine and how I expected -- just as it works under *nix, too. The 'sibling' child processes can write to each other's memory. However, as soon as any child writes to the second anon + shared mmap() region, the Windows memory usage goes up by an amount which (exactly!?) matches the size of that region -- BTW: this is something like 600KB. It takes only a few minutes until all my virtual memory is used up and then Windows does do all those funny things and finally barfs on me ;-) Is there a hidden hierarchy in CYGWIN's mmap() implementation? Or with other words, is writing to an anon + shared mmap()ed region from a sibling process that is not a direct descendant of the parent that created a memory map, but rather a child of another process created by a uber-parent which already exited, something that should work? I must admit that I am confused by my own code right now and even more by the mmap.cc code and comments. I'm not an experienced multi process + daemon author either. For now I sticked up, because crashing OSes make me sick ;-) > Corinna Ciao, Juergen [1] I don't know the for this tool in english Windows versions. I watched the "other memory" display, ie. last entry of the list of watchable items. [2] I guess you know the fork2() stuff. It is described at e.g. http://www.erlenstar.demon.co.uk/unix/faq_toc.html#TOC88 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9T0YbtCKWJo++MqgRAly5AKD8la53lHFT2JL4I/QGyOTW/KnzlQCfZq3i C5e9CqGBiyNIzc6WvGIaBwE= =F82z -----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/