* bug in libc with glob and /proc?
@ 2018-05-16 2:29 Ed Peschko
2018-05-16 3:04 ` Paul Pluzhnikov via libc-help
2018-05-16 17:54 ` Adhemerval Zanella
0 siblings, 2 replies; 3+ messages in thread
From: Ed Peschko @ 2018-05-16 2:29 UTC (permalink / raw)
To: libc-help
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..
^ permalink raw reply [flat|nested] 3+ messages in thread
* 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: Paul Pluzhnikov via libc-help @ 2018-05-16 3:04 UTC (permalink / raw)
To: horos22; +Cc: 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* 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
end of thread, other threads:[~2018-05-16 17:54 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).