Bug 41393

Summary: slocate gets a segfault while reading a large amount of subdirectories
Product: [Retired] Red Hat Linux Reporter: Thor Fridriksson <thorf>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED CURRENTRELEASE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: fweimer, jakub
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-12-15 15:01:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Thor Fridriksson 2001-05-19 20:54:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19 i586; Nav)

Description of problem:
When I've got a huge amount of subdirectories and run slocate to create a
slocate database, slocate gets a segfault. I'm talking about _ALOT_ of
subdirectories.

How reproducible:
Always

Steps to Reproduce:
1. Create a huge amount of subdirectories (asdf/asdf/asdf/asdf/asdf style),
just use cp dir dir -Rf or something
2. Run slocate/updatedb to create an slocate database, like it's run by
default by cron (/usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e
"/tmp,/var/tmp,/usr/tmp,/afs,/net" as root ofcourse, you might want to add
-v to see what files slocate is processing)
	

Actual Results:  after i ran updatedb i got:
/usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" -e
"/tmp,/var/tmp,/usr/tmp,/afs,/net"  
warning: updatedb: could not open database: /var/lib/slocate/slocate.db: No
such file or directory
Segmentation fault



Expected Results:  Well, first of all, it shouldn't segfault, normally it
just completes and creates a database, then exit's with out a message.

Additional info:

Here's what i got when i ran the program through gdb:

[root@tannbursti /]# gdb
/usr/bin/updatedb                                     
GNU gdb 5.0
Copyright 2000 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 "i386-redhat-linux"...
(gdb) run -f "nfs,smbfs,ncpfs,proc,devpts" -e
"/tmp,/var/tmp,/usr/tmp,/afs,/net"Starting program: /usr/bin/updatedb -f
"nfs,smbfs,ncpfs,proc,devpts" -e "/tmp,/var/tmp,/usr/tmp,/afs,/net"
warning: updatedb: could not open database: /var/lib/slocate/slocate.db: No
such file or directory

Program received signal SIGSEGV, Segmentation fault.
strcat (dest=0x80548d8 '*' <repeats 200 times>..., 
    src=0x80548d8 '*' <repeats 200 times>...) at
../sysdeps/generic/strcat.c:46
46	../sysdeps/generic/strcat.c: No such file or directory.
(gdb) 

---

Sometimes i've also got this error:
Program received signal SIGSEGV, Segmentation fault.
0x400cebc4 in __opendir (name=0x80948f4 <Address 0x80948f4 out of bounds>)
    at ../sysdeps/unix/opendir.c:84
84	../sysdeps/unix/opendir.c: No such file or directory.

---

I ran this on Redhat 7.0, with slocate: Secure Locate 2.5 - Released
December 30, 2000,
this could be a security bug, i think so, slocate is: 
-rwxr-sr-x    1 root     slocate     78495 May  4 17:41 /usr/bin/slocate
You could get slocate gid, right?

This is the first bug i submit, sorry for my english, it's not my native
language.

Comment 1 Bill Nottingham 2001-05-21 18:15:33 UTC
Does the version from 7.1 work better?

Comment 2 Thor Fridriksson 2001-05-30 04:22:28 UTC
No, my friend tested it on 7.1, it crashed

Comment 3 Bill Nottingham 2001-06-11 17:15:24 UTC
Can you tar up the directory structure (no files) and post it?

Comment 4 Bill Nottingham 2001-06-11 19:08:17 UTC
Never mind, I seem to have reproduced something similar.

Comment 5 Bill Nottingham 2001-06-11 20:45:17 UTC
Adding jakub to cc: list, this may be a glibc problem.

Comment 6 Alan Cox 2002-12-15 15:01:59 UTC
Seems all fixed and happy by 8.0