Re: segment fault with locate command

[James Youngman]

On 8/18/07, Keith Mitchell <address@hidden> wrote:
> hello,
>
> I am new to linux, and I just got a segement fault while using the
> locate command.

Gosh.  We hope that never happens.

> the situation is -
> 1) First a segment fault was caused by eaccelerator (php accelerator)
> on my server. this took apache offline.

Hmm, I don't really know much about that.

> 2) I have restarted apache and now I have segment faults when using
> the locate command. basically I cannot see the full path of the
> matching pattern I cam trying to locate . any suggestions?


At first thought, the two things don't relate to each other much.

> I am running suse 9.0, apache2 , php 5.16 and locate version 4.17

There has never been a locate version 4.17.   Do you mean 4.1.7?   If
so, that's very old indeed (_years_).

> is there some place to get some support?

Absolutely, in fact this mailing list is the right place.

So, there are two things we can do:

1. Try to understand what is happening
2. Try to fix it.

They may or not be related, but probably are.  First things first;
every night a cron job will rebuild your locate database.  So in case
your problem is data-specific we need you to save a copy of your
current locate database.  I don't have a SUSE system, but will try to
help as best I can.   Find the path to your "locate" binary.  It's
probably in /usr/bin/locate.     If you really are using locate
version 4.1.7, running "locate --version" should result in this
output:-

GNU locate version 4.1

If you are using Bash as your shell, you can figure out where locate
is with "type locate":-

$ type locate
locate is /usr/local/bin/locate

While modern versions of locate do provide an easy way to find out
where the locate database is, 4.1.7 did not (it's very old).  Do this
to find out:-

$ strings /usr/local/bin/locate | grep locatedb

Where I use /usr/local/bin/locate you need to use the path that "type"
told you.  I get this output when I do that:-

/usr/local/var/locatedb

So that's the location of my locate database.  Yours is probably
different.   Anyway, save a copy of that file (e.g. with "cp") in case
regeneration of the database makes the problem go away.

That deals with preserving the evidence.  Next, try to establish if
the binary is intact.  We can do this by running it.  "locate
--version" and "locate --help" should produce some helpful looking
messages like this:

$ ./locate --help
Usage: ./locate [-d path] [--database=path] [--version] [--help] pattern...
$ ./locate --version
GNU locate version 4.1

If you get something different (such as another segmentation fault)
then it's likely that your binary has simply become corrupted, which
would probably be an indication that there was something wrong with
your disk or RAM.

If, on the other hand, you do get sensible looking output, the next
step is to try to get a coredump out of it.  Do this:-

ulimit -c unlimited

Now, run whatever locate command produces a segmentation fault.  A
file named "core"   (or occasionally, core.NNNN) will appear in the
current directory.  Next, use the debugger to analyse the core dump
(you will get slightly different output):

$ gdb locate  core
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Failed to read a valid object file image from memory.
Core was generated by
`/home/james/source/GNU/findutils/tarfiles/historic/.tmp/findutils-4.1/locate/locate'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7e71bde in write () from /lib/libc.so.6
(gdb) backtrace
#0  0xb7e71bde in write () from /lib/libc.so.6
#1  0xb7e11984 in _IO_file_write () from /lib/libc.so.6
#2  0xb7e115e5 in ?? () from /lib/libc.so.6
#3  0xb7e1192f in _IO_do_write () from /lib/libc.so.6
#4  0xb7e12239 in _IO_file_overflow () from /lib/libc.so.6
#5  0xb7e117dc in _IO_file_xsputn () from /lib/libc.so.6
#6  0xb7e08a19 in puts () from /lib/libc.so.6
#7  0x080491b7 in main (argc=2, argv=0xbf8f8a94) at locate.c:312
(gdb) quit

It's likely that your "locate" binary was built by your distribution
vendor without debugging information being included.  That probably
means that the coredump will only be of limited use.   However, before
we go further I think you should verify the integrity of your
findutils package, too.   I'm not completely sure how you do this in
SUSE, but I suspect that "rpm --verify findutils" will probably work.
Another possibility is that a library has become corrupted, so if you
could also verify the integrity of the system C library too, that
would be great (the system C library is the only dynamic library that
locate will be linked against).

Thanks,
James