* Matthew Khouzam ([email protected]) wrote:
>
> Signed-off-by: Matthew Khouzam <[email protected]>
> ---
> libustctl/libustctl.c | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/libustctl/libustctl.c b/libustctl/libustctl.c
> index d57e645..443cbb9 100644
> --- a/libustctl/libustctl.c
> +++ b/libustctl/libustctl.c
> @@ -92,6 +92,8 @@ pid_t *ustctl_get_online_pids(void)
> {
> struct dirent *dirent;
> DIR *dir;
> + DIR *proc_dir;
> + char proc_dir_path[PATH_MAX];
> unsigned int ret_size = 1 * sizeof(pid_t), i = 0;
>
> dir = opendir(SOCK_DIR);
> @@ -117,7 +119,17 @@ pid_t *ustctl_get_online_pids(void)
> * We need to figure out an intelligent way of solving
> * this, maybe connect-disconnect.
> */
> - if (1) {
> + snprintf(proc_dir_path, PATH_MAX, "/proc/%u/", ret[i]);
> + proc_dir = opendir(proc_dir_path);
Where do you free proc_dir ? I think you have a memory leak here.
> + /*
> + * Note:
> + * maybe we should remove the empty dir in this pass
> + * too. Since the detection method is not perfect,
> + * this step is not yet implemented.
> + * A process can die, and its pid can be still taken
> + * when reading online pids.
Yes, that's racy. We can have a new process coming up and reusing a PID
of an old process that died concurrently with us poking /proc to see
which processes are there. So deleting the socket file non-atomically
with the /proc PID dir verifcation is really asking for trouble.
The only way I can see us doing the socket file removal relatively
racelessly is if we synchronize the creation/removal of these files in a
centralized place, e.g. in ltt-sessiond eventually.
Could you update your comment to reflect this thought ?
Thanks,
Mathieu
> + */
> + if (proc_dir) {
> ret_size += sizeof(pid_t);
> ret = (pid_t *) realloc(ret, ret_size);
> ++i;
> --
> 1.7.0.4
>
>
> _______________________________________________
> ltt-dev mailing list
> [email protected]
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
