When using this command:
grep -P '\?>\s' *
I get a core dump. Likewise with the -r option as well, as in:
grep -r -P '\?>\s' *
###################
The problem is reliably reproducible. It in fact dumps core every
single time I run it with these options and it finds something
matching. It also always dumps on files containing '?>' with no
trailing whitspace. It even dumps on a file containing only '?>'. It
does not on files containing only '?' or on a file consisting of '?
>'.
###################
my grep is:
grep (GNU grep) 2.5.1
Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
My install is via Mandriva RPM from the 2006.0 release:
# rpm -qa |grep grep
grep-2.5.1a-1mdk
rgrep-0.99.17-0.111.2mdk
###################
I also get the same behavior with a fresh build of 2.5.1a downloaded
from ftp.gnu.org and built on this platform via a simple configure and
make on this system.
# md5sum grep
f5861cf66f64970df1191309c4cc8168 grep
In the source directory for this build, it also finds many lines which
have no apparent business matching '\?>\s'. See attachment
'bad_grep.txt' for those results.
###################
My platform is:
Mandriva 2006.0 on AMD
# uname -a
Linux serverman-x 2.6.12-12mdk #1 Fri Sep 9 18:15:22 CEST 2005 i686
AMD Athlon(tm) Processor unknown GNU/Linux
####################
The processor is:
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 4
model name : AMD Athlon(tm) Processor
stepping : 2
cpu MHz : 1009.328
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca
cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 1998.84
######################
I don't have another proper environment with which to test, but I do
have Windows. The grep 2.5.1 which is compiled as part of the GNU
ports to Windows at http://unxutils.sourceforge.net/ makes my command
prompt window scroll wildly, beep much (probably jsut embedded \cg
chars in the output), and eventually stop responding with the command:
grep -P "\?>\s" foo
where 'foo' is the name of the file containing '?>'. It seems to
behave normally with the files consisting of '?' or '? >', but it
return an exit code of 1. It seems, though, that this build of grep
always does when it completes -- even when not using the -P switch.
I wish I could offer a patch, but time and limited skills with C
prohibit. I have saved several but not all of the core files in case
those are needed. If this is a PCRE library issue, I would be happy to
make that bug report but I can only guess the grep team would have
more interesting and accurate things to tell the PCRE team than I.
Christopher E. Stith
foo:?>
bin/sh
exec grep -F ${1+"$@"}
rrectly treating binary, Unix text
and DOS text files.
This has several aspects:
* Guessing the file type (unless the user tells us);
* Stripping CR characters from DOS text files (otherwise regex
functions won't work correctly);
* Reporting correct byte count with -b for any kind of file.
*/
typedef enum {
UNKNOWN, DOS_BINARY, DOS_TEXT, UNIX_TEXT
} File_type;
struct dos_map {
off_t pos; /* position in buffer passed to matcher */
off_t add; /* how much to add when reporting char position */
};
static int dos_report_unix_offset = 0;
static File_type dos_file_type = UNKNOWN;
static File_type dos_use_file_type = UNKNOWN;
static off_t dos_stripped_crs = 0;
static struct dos_map *dos_pos_map;
static int dos_pos_map_size = 0;
static int dos_pos_map_used = 0;
static int inp_map_idx = 0, out_map_idx = 1;
/* Guess DOS file type by looking at its contents. */
static inline File_type
guess_type (char *buf, Segmentation fault (core dumped)
