https://bugs.exim.org/show_bug.cgi?id=1803
--- Comment #9 from Nish Aravamudan <nish.aravamudan@???> ---
(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.
