bug in libc with glob and /proc?

bug in libc with glob and /proc?

[Ed Peschko]

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..

Re: bug in libc with glob and /proc?

[Paul Pluzhnikov via libc-help]

On Tue, May 15, 2018 at 7:29 PM Ed Peschko <horos22@gmail.com> wrote:

>   Is there something about /proc that is special here? Shouldn't glibc
> be able to handle it transparently?

There are a lot of things that are strange about /proc.

Filing a bugzilla issue with a small reproducer should be your first step.
Running your test program under strace may also provide some clues.

-- 
Paul Pluzhnikov

Re: bug in libc with glob and /proc?

[Adhemerval Zanella]

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?