Bug #6278 for File-Locate: Segmentation fault

Mon May 10 12:34:30 2004 Guest - Ticket created

Subject:

Segmentation fault

The following script (ever so slightly modified from the documentation's example script) generates a segfault: #!/usr/bin/perl -w use strict; use File::Locate; print join "\n", locate "analyze_log.sh", "/var/lib/slocate/slocate.db"; Here's my output from perl -V: Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=linux, osvers=2.4.20-30.9, archname=i686-linux uname='linux removed_by_afoxson 2.4.20-30.9 #1 wed feb 4 20:44:26 est 2004 i686 i686 i386 gnulinux ' config_args='-de' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm' , optimize='-O2', cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.3.2.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Apr 29 2004 09:43:18 @INC: /usr/local/lib/perl5/5.8.4/i686-linux /usr/local/lib/perl5/5.8.4 /usr/local/lib/perl5/site_perl/5.8.4/i686-linux /usr/local/lib/perl5/site_perl/5.8.4 /usr/local/lib/perl5/site_perl . This is a Red Hat Linux 9.0 box. See the attachment for the output from strace. Thanks for your time.

Download strace.log
application/octet-stream 25k

Message body not shown because it is not plain text.

Mon May 10 13:29:06 2004 tassilo.parseval [...] post.rwth-aachen.de - Correspondence added

Date:	Mon, 10 May 2004 19:27:06 +0200
From:	Tassilo von Parseval <tassilo.parseval [...] post.rwth-aachen.de>
Subject:	Re: [cpan #6278] Segmentation fault
To:	Guest via RT <bug-File-Locate [...] rt.cpan.org>
RT-Send-Cc:

On Mon, May 10, 2004 at 12:34:31PM -0400 Guest via RT wrote: Show quoted text

> This message about File-Locate was sent to you by guest <> via rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=6278 > > > The following script (ever so slightly modified from the documentation's example script) generates a segfault: > > #!/usr/bin/perl -w > > use strict; > use File::Locate; > > print join "\n", locate "analyze_log.sh", "/var/lib/slocate/slocate.db";

Thank you for your report. locate and slocate use two different kind of db-formats (as I just figured out through some empirical tests). That unfortunately means that File::Locate cannot deal with slocate databases as of yet (the plain locate program will also segfault on an slocate.db). I haven't yet looked at slocate's innards too closely but I see some vague chances to add a corresponding slocate() function. Thanks for making me aware of that. Tassilo -- $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({ pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#; $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval

Mon May 10 13:43:17 2004 Guest - Correspondence added

Show quoted text

> locate and slocate use two different kind of db-formats (as I just > figured out through some empirical tests). That unfortunately means > that > File::Locate cannot deal with slocate databases as of yet (the plain > locate program will also segfault on an slocate.db). I haven't yet > looked at slocate's innards too closely but I see some vague chances > to > add a corresponding slocate() function. Thanks for making me aware of > that.

Ah, yes, of course. I very much look forward to slocate support in File::Locate. Particularly because many systems nowadays default to slocate, without even installing the old locate beside it. Infact, on my systems, the vendor has chosen to symlink locate to slocate. Also, slocate is ostensibly more secure; Not many people would be terribly excited about having to install and run the old locate. :-) Further, slocate support in File::Locate would benefit those that are constrained to tight environments where local policy may not allow for installation of non-default/approved packages without undergoing a major review process, especially if it's a potential security liability. Many thanks for your time and several excellent CPAN distributions.

Mon May 10 14:38:58 2004 Guest - Correspondence added

Show quoted text

> locate and slocate use two different kind of db-formats (as I just > figured out through some empirical tests). That unfortunately means > that > File::Locate cannot deal with slocate databases as of yet (the plain > locate program will also segfault on an slocate.db). I haven't yet > looked at slocate's innards too closely but I see some vague chances > to > add a corresponding slocate() function. Thanks for making me aware of > that.

Ah, yes, of course. I very much look forward to slocate support in File::Locate. Particularly because many systems nowadays default to slocate, without even installing the old locate beside it. Infact, on my systems, the vendor has chosen to symlink locate to slocate. Also, slocate is ostensibly more secure; Not many people would be terribly excited about having to install and run the old locate. :-) Further, slocate support in File::Locate would benefit those that are constrained to tight environments where local policy may not allow for installation of non-default/approved packages without undergoing a major review process, especially if it's a potential security liability. Many thanks for your time and several excellent CPAN distributions.

Mon May 10 14:39:07 2004 Guest - Correspondence added

Show quoted text

> locate and slocate use two different kind of db-formats (as I just > figured out through some empirical tests). That unfortunately means > that > File::Locate cannot deal with slocate databases as of yet (the plain > locate program will also segfault on an slocate.db). I haven't yet > looked at slocate's innards too closely but I see some vague chances > to > add a corresponding slocate() function. Thanks for making me aware of > that.

Ah, yes, of course. I very much look forward to slocate support in File::Locate. Particularly because many systems nowadays default to slocate, without even installing the old locate beside it. Infact, on my systems, the vendor has chosen to symlink locate to slocate. Also, slocate is ostensibly more secure; Not many people would be terribly excited about having to install and run the old locate. :-) Further, slocate support in File::Locate would benefit those that are constrained to tight environments where local policy may not allow for installation of non-default/approved packages without undergoing a major review process, especially if it's a potential security liability. Many thanks for your time and several excellent CPAN distributions.

Mon May 10 14:41:22 2004 FOX [...] cpan.org - Correspondence added

Eeep. RT bug. Don't mind the duplicate posts. :-)

Tue May 11 04:29:30 2004 tassilo.parseval [...] post.rwth-aachen.de - Correspondence added

Date:	Tue, 11 May 2004 10:18:28 +0200
From:	Tassilo von Parseval <tassilo.parseval [...] post.rwth-aachen.de>
Subject:	Re: [cpan #6278] Segmentation fault
To:	Guest via RT <bug-File-Locate [...] rt.cpan.org>
RT-Send-Cc:

On Mon, May 10, 2004 at 01:43:18PM -0400 Guest via RT wrote: Show quoted text

> This message about File-Locate was sent to you by guest <> via rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=6278 > >

> > locate and slocate use two different kind of db-formats (as I just > > figured out through some empirical tests). That unfortunately means > > that > > File::Locate cannot deal with slocate databases as of yet (the plain > > locate program will also segfault on an slocate.db). I haven't yet > > looked at slocate's innards too closely but I see some vague chances > > to > > add a corresponding slocate() function. Thanks for making me aware of > > that.

> > Ah, yes, of course. I very much look forward to slocate support in > File::Locate. Particularly because many systems nowadays default to > slocate, without even installing the old locate beside it. Infact, on > my systems, the vendor has chosen to symlink locate to slocate. Also, > slocate is ostensibly more secure; Not many people would be terribly > excited about having to install and run the old locate. :-) > > Further, slocate support in File::Locate would benefit those that are > constrained to tight environments where local policy may not allow for > installation of non-default/approved packages without undergoing a > major review process, especially if it's a potential security liability.

Makes sense. Till yesterday, I wasn't even aware of slocate. I am right now diddling it into File::Locate so expect a new release soon (after which I can probably also close this ticket if I figure out how to do it). Tassilo -- $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({ pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#; $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval

Sat May 15 11:54:39 2004 VPARSEVAL [...] cpan.org - Correspondence added

0.60 just hit the CPAN and fixes the segfault. locate() can now read both locate- and slocate-databases.

Sat May 15 11:54:40 2004 VPARSEVAL [...] cpan.org - Status changed from 'new' to 'resolved'

Mon May 17 09:28:14 2004 Guest - Correspondence added

[VPARSEVAL - Sat May 15 11:54:39 2004]: Show quoted text

> 0.60 just hit the CPAN and fixes the segfault. locate() can now read > both locate- and slocate-databases.

Thank you, kindly. :-)

Mon May 17 09:28:15 2004 The RT System itself - Status changed from 'resolved' to 'open'

Tue Jul 20 11:53:51 2004 VPARSEVAL [...] cpan.org - Status changed from 'open' to 'resolved'