* Re: bug in libc with glob and /proc?
2018-05-16 2:29 bug in libc with glob and /proc? Ed Peschko
2018-05-16 3:04 ` Paul Pluzhnikov via libc-help
@ 2018-05-16 17:54 ` Adhemerval Zanella
1 sibling, 0 replies; 3+ messages in thread
From: Adhemerval Zanella @ 2018-05-16 17:54 UTC (permalink / raw)
To: libc-help
On 15/05/2018 23:29, Ed Peschko wrote:
> all,
>
> i'm getting something very odd with glob and /proc:
>
> I am trying to write a quick process check module - one that I want to
> be exceedingly small and therefore to have the fewest possible
> dependencies (ie: no libproc)
>
> So I was writing calls like this:
>
> proc_stat = glob("/proc/[0-9]*/cmdline", 0, NULL, &paths);
> ...
> globfree(&paths)
>
>
> Oddly, this only returns results on the very first call - the second
> returns that no results are to be found (GLOB_NOMATCH).
>
> If however, I replace "/proc" with "/tmp" or any other value, it works
> robustly - the only line of code changing being the call to glob.
>
> Hence I really don't think it is a coding error on my part (i'll post
> the full code if so desired).
>
> Therefore, I'm leaning towards thinking it is a glibc bug and will
> file it as so if necessary. This is on centos 7.5 btw for context.
>
> so - what is going on here? weird things are also happing here when I
> try to popen out and do the same logic against /proc.
>
> Is there something about /proc that is special here? Shouldn't glibc
> be able to handle it transparently?
>
> thanks much for any info/help..
>
The underlying filesystem can indeed interfere with glob results, especially
how it handles getdents and stat syscalls. I won't be surprised if centos 7.5
kernel might be doing something funny with some entries, specially because
glob code handle different fs in the same manner.
For instance, this follow testcase:
$ cat test.c
#include <stdio.h>
#include <glob.h>
int main ()
{
glob_t paths;
int ret;
ret = glob ("/proc/[0-9]*/cmdline", 0, NULL, &paths);
printf ("ret=%d\n", ret);
printf ("paths.gl_pathc=%zu\n", paths.gl_pathc);
for (size_t i = 0; i < paths.gl_pathc; i++)
printf("%s\n", paths.gl_pathv[i]);
printf ("\n");
globfree (&paths);
ret = glob ("/proc/[0-9]*/cmdline", 0, NULL, &paths);
printf ("ret=%d\n", ret);
printf ("paths.gl_pathc=%zu\n", paths.gl_pathc);
for (size_t i = 0; i < paths.gl_pathc; i++)
printf("%s\n", paths.gl_pathv[i]);
printf ("\n");
globfree (&paths);
return 0;
}
When building on Ubuntu 16.04 (kernel 4.4.0, glibc 2.23) shows:
$ gcc test3.c -o test
$ ./test | grep gl_pathc
paths.gl_pathc=384
paths.gl_pathc=384
So no issues as you reported (assuming if it is what you are doing).
Could you provide a testcase and check if glibc master with a different
kernel also shows the same issue?
^ permalink raw reply [flat|nested] 3+ messages in thread