Bug 164637

Created attachment 117277 [details]
Patch you can apply to updatedb.conf, maybe by hand it may be faster

Thanks for your report.

proc, sysfs and similar filesystems are excluded in /etc/cron.daily/slocate.cron;
that code will handle any new nodev filesystems used by the kernel, so
adding proc to /etc/updatedb.conf is just redundant.

Rather than avoiding the problem, the crash should be fixed; I'll try to find
the cause.

(In reply to comment #2)
> proc, sysfs and similar filesystems are excluded in /etc/cron.daily/slocate.cron;
> that code will handle any new nodev filesystems used by the kernel, so
> adding proc to /etc/updatedb.conf is just redundant.
Results of updatedb by hand and by cron should be the same. Maybe it could be
better to write script updatedb instead of symlinking slocate, that will control
/proc/filesystems as well.

Just a thought...
> 
> Rather than avoiding the problem, the crash should be fixed; I'll try to find
> the cause.
The problem is here
main.c:1093:       fts_close(dir);
but i don't have now time to debug (??glibc bug??).

I can't reproduce the problem so far.
- What does "at this file /proc/net/rpc/flush" mean?
- Does the crash happen every time?
- Does (rpm -V slocate) report anything?
- If the crash is reproducible, can you please install the debuginfo package
  and run (valgrind --tool=memcheck --num-callers=20 updatedb) ?.

(In reply to comment #4)
> I can't reproduce the problem so far.
> - What does "at this file /proc/net/rpc/flush" mean?
I don't know now, it isn't there.

> - Does the crash happen every time?
Yeah, it did (on the same file ?or dir?).

> - Does (rpm -V slocate) report anything?
no, rpm was ok, i tried my own compiled slocate and run it from . without results.

> - If the crash is reproducible, can you please install the debuginfo package
>   and run (valgrind --tool=memcheck --num-callers=20 updatedb) ?.
No, it isn't now.

Sorry for wasting your time, maybe it could be a kernel bug:
find: WARNING: Hard link count is wrong for /proc: this may be a bug in your
filesystem driver.  Automatically turning on find's -noleaf option.  Earlier
results may have failed to include directories that should have been searched.

I'll dig into the problem and let you know.

Thanks for your quick reply.

(In reply to comment #5)
> > - What does "at this file /proc/net/rpc/flush" mean?
> I don't know now, it isn't there.
That's why I am asking :)

> > - Does the crash happen every time?
> Yeah, it did (on the same file ?or dir?).
How do you know it happens on the same file?

> Sorry for wasting your time, maybe it could be a kernel bug:
> find: WARNING: Hard link count is wrong for /proc: this may be a bug in your
> filesystem driver.  Automatically turning on find's -noleaf option.  Earlier
> results may have failed to include directories that should have been searched.
This could be related, but slocate still should not crash.  Nevertheless,
slocate runs fine here even though find reports the same warning.

> I'll dig into the problem and let you know.
Thanks, please reset the bug to the ASSIGNED state when you discover anything.

(In reply to comment #6)
> > > - Does the crash happen every time?
> > Yeah, it did (on the same file ?or dir?).
> How do you know it happens on the same file?
updatedb -v
started 5 times (and it stopped on the same file or dir or what was it)

> > Sorry for wasting your time, maybe it could be a kernel bug:
> > find: WARNING: Hard link count is wrong for /proc: this may be a bug in your
> > filesystem driver.  Automatically turning on find's -noleaf option.  Earlier
> > results may have failed to include directories that should have been searched.
> This could be related, but slocate still should not crash.  Nevertheless,
> slocate runs fine here even though find reports the same warning.
Maybe there could be some "bigger" underrun if the file was there (nfs creates
it in some cases: drivers/net/sunrpc/cache.c, but i don't when).
Now the warning is here, but updatedb runs ok, as you write.

> > I'll dig into the problem and let you know.
> Thanks, please reset the bug to the ASSIGNED state when you discover anything.
It was a mistake, i didn't want to change the state :(.

(In reply to comment #7)
> (In reply to comment #6)
> > > > - Does the crash happen every time?
> > > Yeah, it did (on the same file ?or dir?).
> > How do you know it happens on the same file?
> updatedb -v
> started 5 times (and it stopped on the same file or dir or what was it)
Thanks, that was missing from the original description.

> Maybe there could be some "bigger" underrun if the file was there (nfs creates
> it in some cases: drivers/net/sunrpc/cache.c, but i don't when).
> Now the warning is here, but updatedb runs ok, as you write.
linux/net/sunrpc/cache.c:cache_register() can AFAICS only create
/proc/net/rpc/$something/flush .

> > > I'll dig into the problem and let you know.
> > Thanks, please reset the bug to the ASSIGNED state when you discover anything.
> It was a mistake, i didn't want to change the state :(.
It probably wasn't your mistake then; bugzilla might be doing it automatically.


One more question: at the time updatedb was crashing, were there any
very deep directory hierarchies (absolute path names longer than roughly 4350
bytes) on the filesystem?

(In reply to comment #8)
> linux/net/sunrpc/cache.c:cache_register() can AFAICS only create
> /proc/net/rpc/$something/flush .
It is possible, but I use recent mm kernels for testing and there could be a bug.
I think, that I haven't used nfs, so I really don't know what the flush was :(.

> One more question: at the time updatedb was crashing, were there any
> very deep directory hierarchies (absolute path names longer than roughly 4350
> bytes) on the filesystem?
I don't think so, I didn't make any big changes and now I have only one file,
that has approx. 250 chars in its abs path.

The new slocate-2.7-22.fc4.1 package fixes several bugs that could cause similar
crashes.

If you find a way to reproduce the original problem (with either -22 or
-22.fc4.1), please reopen this bug.