https://bugs.exim.org/show_bug.cgi?id=1803
--- Comment #9 from Nish Aravamudan <[email protected]> --- (In reply to Zoltan Herczeg from comment #8) > > (gdb) print offsets[0] > > $2 = 2 > > (gdb) print offsets[1] > > $3 = 4 > > This is a perfectly valid offset pair representing the \303\204 single > character substring. So PCRE result seems correct. The question is how the > 0x19...9 length is computed from this offset values. Please do single > stepping until you find out how that value is computed. Right, the issue is the value of last_match relative to these offsets: (gdb) print last_match $6 = 0x7fffed43e1fc "\303\237\343\201\224a" (gdb) print &subject[offsets[0]]-last_match $7 = -2 And PHP is using this last value to determine in the failing line: ZVAL_STRINGL(&tmp, last_match, &subject[offsets[0]]-last_match); After saving off each matching substring, PHP updates last_match to: last_match = &subject[offsets[1]]; I *believe* I saw two calls to pcre_exec return the same offsets (which might be how we get to this state, since the last_match value will be incorrect relative to the offsets (as they should have advanced)). I will try and reproduce today and post the results. -- 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
