delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/06/04/16:12:24

From: cgf AT cygnus DOT com (Christopher Faylor)
Subject: Re: spawn memory leak?
4 Jun 1998 16:12:24 -0700 :
Message-ID: <199806042243.SAA16674.cygnus.cygwin32.developers@kramden.cygnus.com>
To: cygwin32-developers AT cygnus DOT com, newsham AT lava DOT net

>I believe there is a memory leak in the spawn code somewhere.  So far
>we haven't been able to track it down.  We wrote a test case that
>builds an argv/envp with some extra garbage in it that invoked
>a hello-world program repeatedly with spawnve and _P_NOWAIT.  We looped 
>over the spawn with a sleep(1) in between.  Watching the VMSize and
>MemUsage in the task manager showed the process was accumulating more
>and more memory.  Replacing the spawnve with fork+exec code resulted
>in a program that did not accumulate memory.  I can post test cases
>we used if desired.

winenv() allocates memory.  There may be a leak in there somewhere.

>The only allocation I saw in the spawn functions themselves were
>alloca calls which auto-free since they're on the stack (I ran tests
>to verify alloca was working properly in the dll, too).  I didn't
>go tracing through every called procedure yet.
>
>Btw, what is linearize_fd_array for, and why does the spawn code
>use it (while the fork code doesn't appear to)?

linearize_fd_array puts fhandle information for fds into contiguous
memory so that it can be easily passed to a spawned process in one chunk.

fork() doesn't need it because the information is duplicated automatically
when the heap and data segment are copied.

cgf

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019