https://bugs.exim.org/show_bug.cgi?id=1803
--- Comment #25 from Nish Aravamudan <nish.aravamudan@???> ---
(In reply to Zoltan Herczeg from comment #23)
> Thank you!
>
> > /(?<!^)(?!$)/u
>
> This is a tricky pattern, since it matches to an empty string. But other
> than that nothing special with it.
>
> I tried matching it from offset 4 in UTF mode, and the result was 4,4 here.
> And that is the expected.
I should reiterate that, here too -- when I run this particular testcase from
twig on its own (just like `phpunit --process-isolation` does, which does
work), I don't see any problem. So I'm not 100% sure it's this pattern in this
execution that is bad, but some state somewhere (could be php, could be
libpcre) is getting corrupted.
> This is still the most confusing part for me:
>
> Breakpoint 8, php_pcre_split_impl (pce=0x555555d33520,
> subject=0x7fffed42e248 "\303\251\303\204\303\237\343\201\224a",
> subject_len=10, return_value=0x7ffff381b240, limit_val=-1,
> flags=<optimized out>)
> at /build/php7.0-WHFaJZ/php7.0-7.0.3/ext/pcre/php_pcre.c:1794
> 1794 if (count == 0) {
> (gdb) print offsets[0]
> $52 = -1
> (gdb) print offsets[1]
> $53 = -1
> (gdb) c
> Continuing.
>
> JIT cannot return with -1 in offsets[0], except if the original value was
> -1, and there is no match.
>
> I really would like to see the value of count before the crash, and I think
> it is in $eax or $rax (disassemble can confirm it).
>
> Please print offsets[0] and [1] before and after pcre_exec is called. Please
> also print g_notempty as well.
Will do!
--
You are receiving this mail because:
You are on the CC list for the bug.
