This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug in libc with glob and /proc?



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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]