Mail Archives: cygwin/2002/08/06/00:37:43
-----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/
- Raw text -