https://bugs.exim.org/show_bug.cgi?id=1803
--- Comment #25 from Nish Aravamudan <[email protected]> --- (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. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
