You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Cliff Woolley <jw...@virginia.edu> on 2002/05/24 01:39:29 UTC
match_boyer_moore_horspool() looping on icarus
Root: FYI, Greg Ames gave me the heads up and I've killed this one child
off... it seems to be a relatively odd input that caused the loop, so I
won't back icarus down to the ancient 2.0.18 nor to 2.0.36 for now... I'll
just leave it on 2.0.37-dev and keep a closer eye on it.
For everyone else, here's the backtrace of the looping process:
(gdb) bt
#0 match_boyer_moore_horspool (this_pattern=0x8111cf0,
s=0x8161dc4 "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; )",
slen=58) at apr_strmatch.c:133
#1 0x806a616 in match_headers (r=0x8161048) at mod_setenvif.c:567
#2 0x809e0ac in ap_run_post_read_request (r=0x8161048) at protocol.c:1591
#3 0x809c89e in ap_read_request (conn=0x815a118) at protocol.c:981
#4 0x806ad28 in ap_process_http_connection (c=0x815a118) at
http_core.c:284
#5 0x8097050 in ap_run_process_connection (c=0x815a118) at
connection.c:85
#6 0x80974dc in ap_process_connection (c=0x815a118, csd=0x815a048)
at connection.c:207
#7 0x80870fa in child_main (child_num_arg=11) at prefork.c:671
#8 0x80872d5 in make_child (s=0x8156670, slot=11) at prefork.c:765
#9 0x80875b7 in perform_idle_server_maintenance (p=0x80d1010) at
prefork.c:900
#10 0x8087a77 in ap_mpm_run (_pconf=0x80d1010, plog=0x8109010,
s=0x8156670)
at prefork.c:1093
#11 0x808f207 in main (argc=1, argv=0xbfbffb2c) at main.c:632
#12 0x805e821 in _start ()
(gdb) info locals
s_tmp = 0x8161df7 ")"
p_tmp = 0x8111ce8 "2"
s_end = 0x8161dfe ""
shift = (int *) 0x8111d00
s_next = 0x8161df7 ")"
p_start = 0x8111ce0 "Mozilla/2"
p_end = 0x8111ce8 "2"
I'll look into this a bit more and report back in a while.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: match_boyer_moore_horspool() looping on icarus
Posted by Brian Pane <bp...@pacbell.net>.
Cliff Woolley wrote:
>And yes, s_next *is* less than s_end. So the question is: why doesn't
>s_next get incremented?
>
>(gdb) p *s_next
>$3 = -71 ''
>(gdb) p shift[*s_next]
>$4 = 0
>
>Ah. Oops.
>
>(Note that -71 is a non-printable superscript 1 or something.)
>
>Perhaps s_next needs to be unsigned?
>
Thanks for catching that. I've just committed a change to
make it unsigned.
--Brian
Re: match_boyer_moore_horspool() looping on icarus
Posted by Cliff Woolley <jw...@virginia.edu>.
On Thu, 23 May 2002, Cliff Woolley wrote:
> > #0 match_boyer_moore_horspool (this_pattern=0x8111cf0,
> > s=0x8161dc4 "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; )",
> > slen=58) at apr_strmatch.c:133
>
> (Note that -71 is a non-printable superscript 1 or something.)
PS: It's not evident from my original message because my terminal program
apparently is refusing to cut-and-paste untypeable characters. Frame #0's
arguments REALLY are:
#0 match_boyer_moore_horspool (this_pattern=0x8111cf0,
s=0x8161dc4 "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; <BE><C6><C6><AE><B9><CC><B5><F0><BE><EE>)", slen=58) at
apr_strmatch.c:133
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: match_boyer_moore_horspool() looping on icarus
Posted by Cliff Woolley <jw...@virginia.edu>.
On Thu, 23 May 2002, Cliff Woolley wrote:
> (gdb) bt
> #0 match_boyer_moore_horspool (this_pattern=0x8111cf0,
> s=0x8161dc4 "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; )",
> slen=58) at apr_strmatch.c:133
> #1 0x806a616 in match_headers (r=0x8161048) at mod_setenvif.c:567
>
> (gdb) info locals
> s_tmp = 0x8161df7 ")"
> p_tmp = 0x8111ce8 "2"
> s_end = 0x8161dfe ""
> shift = (int *) 0x8111d00
> s_next = 0x8161df7 ")"
> p_start = 0x8111ce0 "Mozilla/2"
> p_end = 0x8111ce8 "2"
Okay, the while loop is definitely spinning forever:
(gdb)
122 while (s_next < s_end) {
(gdb)
123 const char *s_tmp = s_next;
(gdb)
124 const char *p_tmp = p_end;
(gdb)
125 while (*s_tmp == *p_tmp) {
(gdb)
132 s_next += shift[(int)*s_next];
(gdb)
133 }
(gdb)
122 while (s_next < s_end) {
(gdb)
123 const char *s_tmp = s_next;
(gdb)
124 const char *p_tmp = p_end;
(gdb)
125 while (*s_tmp == *p_tmp) {
(gdb)
132 s_next += shift[(int)*s_next];
(gdb)
133 }
And yes, s_next *is* less than s_end. So the question is: why doesn't
s_next get incremented?
(gdb) p *s_next
$3 = -71 ''
(gdb) p shift[*s_next]
$4 = 0
Ah. Oops.
(Note that -71 is a non-printable superscript 1 or something.)
Perhaps s_next needs to be unsigned?
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA