Hi,
a fix is landed for this bug. Thanks for your help Petr.
Regards,
Zoltan
Petr Pisar <ppisar@???> írta:
>On Mon, Sep 12, 2011 at 06:55:13PM +0200, Herczeg Zoltán wrote:>
> >
> I have never tried the MIPS impmentation on a MIPS64 system. Would be>
> interesting to see what is happening.>
>>
I did tests on Linux 2.6.39.1 mips64 with n32 user space and I get similar>
segfault. Configured as --enable-jit CFLAGS=-g -O0 for MIPS3. It passes a lot>
of testinput1 expressions but segfaults on:>
>
/word (?:[a-zA-Z0-9]+ ){0,300}otherword/>
word cat dog elephant mussel cow horse canary baboon snake shark the quick brown fox and the lazy dog and several other words getting close to thirty by now I hope>
>
I minimized the test case to:>
>
/(a){0,290}/>
foo >
>
The backtrace:>
>
#0 0x22cf79b8 in ?? ()>
No symbol table info available.>
#1 0x2ab2ea80 in jit_machine_stack_exec (arguments=0x7fff1498, >
function=0x10045ff8) at pcre_jit_compile.c:6305>
convert_executable_func = {executable_func = 0x2ace4008, >
call_executable_func = 0x2ace4008}>
local_area = "\255\206\003\020\000\000\000\000\001\000\000\000\254\206\003\020\254\206\003\020", '\000' <repeats 12 times>"\230, \351\260*\000\000\000\000\b\255\004\020\025\000\000\000\000\033\000\000\002\000\000\000\002\000\000\000\020\000\000\000(\000\000\000\000\000\000\000\b\255\004\020\002\000\000\000\000\360\264*\000\000\000\000X\274\a\020\000\000\000\000\340\\\261*\000\000\000\000\b\255\004\020\004\000\000\000\020\000\000\000\r\000\000\000\b\255\004\020\025\000\000\000\000\360\264*\000\000\000\000\376\177\000\000\000\000\230\351\260*\000\000\000\000X\274\a\020\000\000\000\000\000\360\264*\000\000\000\000\b\255\004\020\360\377\245$\005\000\000\000\000\000\000\000\b\255\004\020\004\000\000\000\000\360\264*\000\000\000\000\020\225\376\177\000\000\000\000@\a\261*", '\000' <repeats 12 times>"\230, \351\260*\000\000\000\000\b\255\004\020\025\000\000\000\000\033\000\000\002\000\000\000"...>
local_stack = {top = 2147390520, base = 2147390520, >
limit = 2147423288, max_limit = 2147423288}>
#2 0x2ab2ecb8 in _pcre_jit_exec (re=0x10044c38, executable_func=0x10045ff8, >
subject=0x100386ad "foo", length=3, start_offset=0, options=0, >
match_limit=10000000, offsets=0x10044a10, offsetcount=4)>
at pcre_jit_compile.c:6352>
function = 0x10045ff8>
convert_executable_func = {executable_func = 0x2, >
call_executable_func = 0x2}>
arguments = {stack = 0x7fff1438, str = 0x100386ad "foo", >
begin = 0x100386ad "foo", end = 0x100386b0 "", offsets = 0x10044a10, >
ptr = 0x0, offsetcount = 4, calllimit = 10000000, notbol = 0 '\000', >
noteol = 0 '\000', notempty = 0 '\000', notempty_atstart = 0 '\000'}>
maxoffsetcount = 4>
retval = 717055616>
#3 0x2ab0a758 in pcre_exec (argument_re=0x10044c38, extra_data=0x10045fa8, >
subject=0x100386ad "foo", length=3, start_offset=0, options=0, >
offsets=0x10044a10, offsetcount=45) at pcre_exec.c:5847>
rc = 268438191>
ocount = 0>
arg_offset_max = 0>
first_byte = -1>
req_byte = -1>
req_byte2 = -1>
newline = 0>
using_temporary_offsets = 0>
anchored = 715950912>
startline = 10>
firstline = 1>
first_byte_caseless = 0>
req_byte_caseless = 0>
utf8 = 0>
match_block = {match_call_count = 268919992, match_limit = 0, >
match_limit_recursion = 0, offset_vector = 0x0, offset_end = 0, >
offset_max = 268919968, nltype = 269048576, nllen = 0, >
name_count = 1, name_entry_size = 715948032, >
name_table = 0x1 <Address 0x1 out of bounds>, nl = "\214\202\254*", >
lcc = 0x0, ctypes = 0x0, offset_overflow = 0, notbol = 0, >
noteol = 268717112, utf8 = 0, jscript_compat = 718100896, >
use_ucp = 0, endonly = 718085568, notempty = 0, >
notempty_atstart = 718066960, hitend = 0, bsr_anycrlf = 718066960, >
start_code = 0x0, start_subject = 0x41 <Address 0x41 out of bounds>, >
end_subject = 0x0, start_match_ptr = 0x1001f310 "\340\341\253*", >
end_match_ptr = 0x0, >
start_used_ptr = 0x12 <Address 0x12 out of bounds>, partial = 0, >
end_offset_top = 9, capture_last = 0, start_offset = 269421368, >
match_function_type = 0, eptrchain = 0x100f23c8, eptrn = 0, >
recursive = 0x100f2328, callout_data = 0x0, >
mark = 0x63 <Address 0x63 out of bounds>, once_target = 0x0}>
md = 0x7fff1580>
tables = 0x0>
start_bits = 0x0>
start_match = 0x100386ad "foo">
end_subject = 0x1 <Address 0x1 out of bounds>>
start_partial = 0x0>
req_byte_ptr = 0x100386ac "">
internal_study = {size = 716042240, flags = 0, >
start_bits = "\320\026\377\177\000\000\000\000\310\344\253*\000\000\000\000X*\000\000\000\000\005\000\000\000\000\000\000", minlength = 718085568}>
study = 0x0>
internal_re = {magic_number = 0, size = 0, options = 0, flags = 0, >
dummy1 = 0, top_bracket = 8864, top_backref = 4111, first_byte = 0, >
req_byte = 0, name_table_offset = 61440, name_entry_size = 10925, >
name_count = 0, ref_count = 0, tables = 0x2aabe23c "H", >
nullpad = 0x0}>
external_re = 0x10044c38>
re = 0x10044c38>
#4 0x10009ca0 in main (argc=2, argv=0x7fff3294) at pcretest.c:2779>
[...]>
>
The top address 0x22cf79b8 is not mapped, so the JIT-compiled function jumped>
to nowhere obviously.>
>
Stepping the code again shows it happens in JIT-compiled code:>
>
Starting program: /home/petr/pcre-8.20-RC1/.libs/pcretest -q -s+ testinput>
/(a){0,290}/>
foo >
>
Breakpoint 2, jit_machine_stack_exec (arguments=0x7fff1498, >
function=0x10045ff8) at pcre_jit_compile.c:6299>
6299 local_stack.top = (sljit_w)&local_area;>
(gdb) n>
6300 local_stack.base = local_stack.top;>
(gdb) >
6301 local_stack.limit = local_stack.base + LOCAL_SPACE_SIZE;>
(gdb) >
6302 local_stack.max_limit = local_stack.limit;>
(gdb) >
6303 arguments->stack = &local_stack;>
(gdb) >
6304 convert_executable_func.executable_func = function->executable_func;>
(gdb) >
6305 return convert_executable_func.call_executable_func(arguments);>
(gdb) >
warning: GDB can't find the start of the function at 0x2ace4008.>
>
GDB is unable to find the start of the function at 0x2ace4008>
and thus can't determine the size of that function's stack frame.>
This means that GDB may be unable to access that stack frame, or>
the frames below it.>
This problem is most likely caused by an invalid program counter or>
stack pointer.>
However, if you think GDB should simply search farther back>
from 0x2ace4008 for code which looks like the beginning of a>
function, you can increase the range of the search using the `set>
heuristic-fence-post' command.>
0x2ace4008 in ?? ()>
(gdb) c>
Continuing.>
>
Program received signal SIGSEGV, Segmentation fault.>
0x22cf79b8 in ?? ()>
>
(gdb) info registers >
zero at v0 v1>
R0 0000000000000000 ffffffffcfffffff 0000000000000000 000000007fff9430 >
a0 a1 a2 a3>
R4 000000007fff1498 000000007ffe944c 00000000100386ac 0000000000000003 >
a4 a5 a6 a7>
R8 0000000000000001 0000000000000000 0000000000989680 0000000010044a10 >
t0 t1 t2 t3>
R12 ffffffffffffffff fffffffff0000000 000000002aac47c0 000000007fff1440 >
s0 s1 s2 s3>
R16 000000007ffe93d0 00000000100386ad 00000000100386b0 000000007fff1438 >
s4 s5 s6 s7>
R20 000000007fff1498 0000000000000001 00000000100f2328 0000000000000063 >
t8 t9 k0 k1>
R24 000000002aab8c40 000000002ace4008 000000000000000a 0000000000000000 >
gp sp s8 ra>
R28 000000002ab4f000 000000007ffe93c0 000000007ffe9430 000000002ab2ea80 >
status lo hi badvaddr>
00000000040044f3 0000000000000090 0000000000000000 0000000022cf79b8 >
cause pc>
0000000010008008 0000000022cf79b8 >
fcsr fir restart>
00000000 00000501 0000000000000000 >
>
I suspected stack size, but it does not depend on in (checked with `unlimited'>
stack size).>
>
>
I guess it does not help much. If you advised how to locate the JIT-compiled>
code I could send its dissasebled code back.>
>
-- Petr>
