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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: _exit() missing WSACleanup() call?


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 05 August 2002 22:12, corinna-cygwin@cygwin.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/


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