On Wed, Nov 29, 2006 at 03:49:02PM +0100, Tom Parker wrote:
> about my system... where exactly does pcregrep crash? A stack trace
> would be nice.
p4-7088:~>for i in $(seq 1 8192); do echo -n Z >>file; done
p4-7088:~>pcregrep '(.)*' file
Segmentation fault
Running it under gdb, using the copy in the build tree (as the installed
version is stripped):
(gdb) run '(.)*' /home/mark/file
Starting program: /home/mark/debian/pcre/pcre3-6.7/.libs/pcregrep '(.)*'
/home/mark/file
Program received signal SIGSEGV, Segmentation fault.
match (eptr=0xbfff842d 'Z' <repeats 200 times>..., ecode=0x804df0f "\vC",
offset_top=4, md=0xbfff72f8, ims=0, eptrb=0xbf800644, flags=2, rdepth=8156)
at ./pcre_exec.c:378
378 {
(gdb) bt
#0 match (eptr=0xbfff842d 'Z' <repeats 200 times>..., ecode=0x804df0f "\vC",
offset_top=4, md=0xbfff72f8, ims=0, eptrb=0xbf800644, flags=2, rdepth=8156)
at ./pcre_exec.c:378
#1 0x40029014 in match (eptr=<value optimized out>,
ecode=<value optimized out>, offset_top=<value optimized out>,
md=0xbfff72f8, ims=0, eptrb=0xbf800644, flags=<value optimized out>,
rdepth=8155) at ./pcre_exec.c:629
#2 0x400255b7 in match (eptr=0xbfff842d 'Z' <repeats 200 times>...,
ecode=<value optimized out>, offset_top=4, md=0xbfff72f8, ims=0,
eptrb=0xbf800e44, flags=<value optimized out>, rdepth=8154)
at ./pcre_exec.c:1190
#3 0x40029014 in match (eptr=<value optimized out>,
ecode=<value optimized out>, offset_top=<value optimized out>,
md=0xbfff72f8, ims=0, eptrb=0xbf800e44, flags=<value optimized out>,
rdepth=8153) at ./pcre_exec.c:629
#4 0x400255b7 in match (eptr=0xbfff842d 'Z' <repeats 200 times>...,
ecode=<value optimized out>, offset_top=4, md=0xbfff72f8, ims=0,
eptrb=0xbf801644, flags=<value optimized out>, rdepth=8152)
at ./pcre_exec.c:1190
and so on for thousands more calls to match(), with alternating calling
addresses. Where it's actually failed is right at the beginning of the
function, before it's got to any code. Looks like a stack overflow?
Ah, yes, if I use ulimit to make my stack size unlimited it works as
expected. (presumably that's what's different about your system).
I don't think there's a bug here. Using lots of stack space for a
pattern like this is not unreasonable, and dying horribly when you run
out is something you don't get a whole lot of control over.
There is a limit recursion feature of PCRE, which the calling program
could use.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
