git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v6 00/16] daemon-win32

From
Pat Thoyts <patthoyts@users.sourceforge.net>
Date
Nov 4, 2010, 01:04 UTC
Message-ID
<87r5f1x5jf.fsf@fox.patthoyts.tk>
In-Reply-To
<AANLkTimcYdQD-En+SfkH5dkaxaWXveuA5Oz-Hn0Cf1v+@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
Show 137 quoted lines
>On Thu, Nov 4, 2010 at 1:28 AM, Pat Thoyts
><patthoyts@users.sourceforge.net> wrote:
>> Erik Faye-Lund <kusmabite@gmail.com> writes:
>>>On Wed, Nov 3, 2010 at 11:18 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>>>> diff --git a/compat/mingw.c b/compat/mingw.c
>>>> index b780200..47e7d26 100644
>>>> --- a/compat/mingw.c
>>>> +++ b/compat/mingw.c
>>>> @@ -1519,8 +1519,10 @@ pid_t waitpid(pid_t pid, int *status, unsigned options)
>>>>        }
>>>>
>>>>        if (pid > 0 && options & WNOHANG) {
>>>> -               if (WAIT_OBJECT_0 != WaitForSingleObject((HANDLE)pid, 0))
>>>> +               if (WAIT_OBJECT_0 != WaitForSingleObject((HANDLE)pid, 0)) {
>>>
>>>AAAND the last one is right here as well:
>>>-              if (WAIT_OBJECT_0 != WaitForSingleObject((HANDLE)pid, 0))
>>>+              if (WAIT_OBJECT_0 != WaitForSingleObject(h, 0)) {
>>>
>>
>> Applying both of these doesn't fix the handle leak when I test
>> this. Looking further I believe it is due to the use of a reallocated
>> array. When you remove a pinfo structure you realloc to the one you
>> found, potentially freeing items you still require.
>>
>
>If this is the reason, then that's a bug. The code TRIES to do the
>right thing by memmove'ing the the entro to be deleted to the end.
>Looking over the code, I still don't see anyhing obviously wrong.
>But...
>
>> Attached is a patch that switches to a linked list for this
>> instead. Using this I no longer accumulate leaked handles.
>>
>> ----
>> From e0c05f8f9ed8729648eea92cf654f357fa884e40 Mon Sep 17 00:00:00 2001
>> From: Pat Thoyts <patthoyts@users.sourceforge.net>
>> Date: Thu, 4 Nov 2010 00:23:08 +0000
>> Subject: [PATCH] win32-daemon: fix handle leaks
>>
>> The use of an array of pinfo structures and the realloc used when cleaning
>> up a closed child can free structures that are still in use. Use a linked
>> list instead.
>> This stops the leaking of handles in the win32-daemon.
>>
>> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
>> ---
>>  compat/mingw.c |   43 ++++++++++++++++++++++++-------------------
>>  1 files changed, 24 insertions(+), 19 deletions(-)
>>
>> diff --git a/compat/mingw.c b/compat/mingw.c
>> index b780200..29f4036 100644
>> --- a/compat/mingw.c
>> +++ b/compat/mingw.c
>> @@ -637,11 +637,12 @@ static int env_compare(const void *a, const void *b)
>>        return strcasecmp(*ea, *eb);
>>  }
>>
>> -struct {
>> +struct pinfo_t {
>> +       struct pinfo_t *next;
>>        pid_t pid;
>>        HANDLE proc;
>> -} *pinfo;
>> -static int num_pinfo;
>> +} pinfo_t;
>> +struct pinfo_t *pinfo = NULL;
>>  CRITICAL_SECTION pinfo_cs;
>>
>>  static pid_t mingw_spawnve_fd(const char *cmd, const char **argv, char **env,
>> @@ -746,10 +747,13 @@ static pid_t mingw_spawnve_fd(const char *cmd, const char **argv, char **env,
>>         * Keep the handle in a list for waitpid.
>>         */
>>        EnterCriticalSection(&pinfo_cs);
>> -       num_pinfo++;
>> -       pinfo = xrealloc(pinfo, sizeof(*pinfo) * num_pinfo);
>> -       pinfo[num_pinfo - 1].pid = pi.dwProcessId;
>> -       pinfo[num_pinfo - 1].proc = pi.hProcess;
>> +       {
>> +               struct pinfo_t *info = xmalloc(sizeof(struct pinfo_t));
>> +               info->pid = pi.dwProcessId;
>> +               info->proc = pi.hProcess;
>> +               info->next = pinfo;
>> +               pinfo = info;
>> +       }
>>        LeaveCriticalSection(&pinfo_cs);
>>
>>        return (pid_t)pi.dwProcessId;
>> @@ -1519,13 +1523,15 @@ pid_t waitpid(pid_t pid, int *status, unsigned options)
>>        }
>>
>>        if (pid > 0 && options & WNOHANG) {
>> -               if (WAIT_OBJECT_0 != WaitForSingleObject((HANDLE)pid, 0))
>> +               if (WAIT_OBJECT_0 != WaitForSingleObject(h, 0)) {
>> +                       CloseHandle(h);
>>                        return 0;
>> +               }
>>                options &= ~WNOHANG;
>>        }
>>
>>        if (options == 0) {
>> -               int i;
>> +               struct pinfo_t **ppinfo;
>>                if (WaitForSingleObject(h, INFINITE) != WAIT_OBJECT_0) {
>>                        CloseHandle(h);
>>                        return 0;
>> @@ -1536,17 +1542,16 @@ pid_t waitpid(pid_t pid, int *status, unsigned options)
>>
>>                EnterCriticalSection(&pinfo_cs);
>>
>> -               for (i = 0; i < num_pinfo; ++i)
>> -                       if (pinfo[i].pid == pid)
>> +               ppinfo = &pinfo;
>> +               while (*ppinfo) {
>> +                       struct pinfo_t *info = *ppinfo;
>> +                       if (info->pid == pid) {
>> +                               CloseHandle(info->proc);
>> +                               *ppinfo = info->next;
>> +                               free(info);
>>                                break;
>> -
>> -               if (i < num_pinfo) {
>> -                       CloseHandle(pinfo[i].proc);
>> -                       memmove(pinfo + i, pinfo + i + 1,
>> -                           sizeof(*pinfo) * (num_pinfo - i - 1));
>> -                       num_pinfo--;
>> -                       pinfo = xrealloc(pinfo,
>> -                           sizeof(*pinfo) * num_pinfo);
>> +                       }
>> +                       ppinfo = &info->next;
>>                }
>>
>>                LeaveCriticalSection(&pinfo_cs);
>
>...yeah, using a linked list is more elegant. Do you mind if I snatch
>your code and leave a comment in the commit message?
>

Sure. When I wrote the comment I'd forgotten about the memmove. So hmmm. However, I just pulled you win32-daemon branch and applied this patch on top. Now there are no more warnings so your union fix is good. As I understand it thats the way to handle this particular warning. ipv6 and ipv4 both still work fine as well.

With my patch a while true; do git ls-remote; done shows no more leaking handles or memory. So the use of a list is fixing something. Looking great now.

-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD
Previous: Erik Faye-LundNext: Erik Faye-Lund
Message 23 of 31 in “daemon-win32”
  1. 00/16 daemon-win32Erik Faye-Lund, Nov 3, 2010
  2. 01/16 mingw: add network-wrappers for daemonErik Faye-Lund, Nov 3, 2010
  3. 02/16 mingw: implement syslogErik Faye-Lund, Nov 3, 2010
  4. 03/16 compat: add inet_pton and inet_ntop prototypesErik Faye-Lund, Nov 3, 2010
  5. 04/16 inet_ntop: fix a couple of old-style declsErik Faye-Lund, Nov 3, 2010
  6. 05/16 mingw: use real pidErik Faye-Lund, Nov 3, 2010
  7. 06/16 mingw: support waitpid with pid > 0 and WNOHANGErik Faye-Lund, Nov 3, 2010
  8. 07/16 mingw: add kill emulationErik Faye-Lund, Nov 3, 2010
  9. 08/16 daemon: use run-command api for async servingErik Faye-Lund, Nov 3, 2010
  10. 09/16 daemon: use full buffered mode for stderrErik Faye-Lund, Nov 3, 2010
  11. 10/16 Improve the mingw getaddrinfo stub to handle more use casesErik Faye-Lund, Nov 3, 2010
  12. 11/16 daemon: get remote host address from root-processErik Faye-Lund, Nov 3, 2010
  13. 12/16 mingw: import poll-emulation from gnulibErik Faye-Lund, Nov 3, 2010
  14. 13/16 mingw: use poll-emulation from gnulibErik Faye-Lund, Nov 3, 2010
  15. 14/16 daemon: use socklen_tErik Faye-Lund, Nov 3, 2010
  16. 15/16 daemon: make --inetd and --detach incompatibleErik Faye-Lund, Nov 3, 2010
  17. 16/16 daemon: opt-out on features that require posixErik Faye-Lund, Nov 3, 2010
  18. Pat ThoytsNov 3, 2010
  19. Erik Faye-LundNov 3, 2010
  20. Erik Faye-LundNov 3, 2010
  21. Pat ThoytsNov 4, 2010
  22. Erik Faye-LundNov 4, 2010
  23. Pat ThoytsNov 4, 2010
  24. Erik Faye-LundNov 3, 2010
  25. Erik Faye-LundNov 4, 2010
  26. Erik Faye-LundNov 4, 2010
  27. Martin StorsjöNov 4, 2010
  28. Erik Faye-LundNov 4, 2010
  29. Martin StorsjöNov 4, 2010
  30. Erik Faye-LundNov 4, 2010
  31. Martin StorsjöNov 4, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.