https://bugs.exim.org/show_bug.cgi?id=1803
Nish Aravamudan <nish.aravamudan@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #45 from Nish Aravamudan <nish.aravamudan@???> ---
(In reply to Zoltan Herczeg from comment #44)
> > $62 = {flags = 115, study_data = 0x555555d33610, match_limit = 1000000,
> > callout_data = 0x0,
> > tables = 0x21e <error: Cannot access memory at address 0x21e>,
> > match_limit_recursion = 100000, mark = 0x7fffffff9288,
> > executable_jit = 0x555555d33650}
>
> The 115 is 0x73, so 0x20 is indeed set in flags. The 0x7fffffff9288 for mark
> is a typical stack address. I thought PCRE_EXTRA_MARK is connected to 's'
> but it is probably not. Perhaps PCRE_EXTRA_MARK is always set.
>
> You are probably right about the issue you found. In the past study data was
> never passed, so setting PCRE_EXTRA_MARK did not cause any problem. But now
> it is, a random memory address is overwritten with NULL.
Yep, I just tested unsetting both the mark value and unsetting PCRE_EXTRA_MARK
in the flags and it passed now!
> I think they really need to change the character advancing to something more
> efficient like:
>
> if (g_notempty != 0 && start_offset < subject_len) {
> offsets[0] = start_offset;
> offsets[1] = start_offset + 1;
> if (pce->compile_options & PCRE_UTF8) {
> while (offsets[1] < subject + subject_len
> && (subject[offsets[1]] & 0xc0) == 0x80) {
> offsets[1]++;
> }
> }
> }
>
> Because using pcre to advancing just one UTF character ahead is the most
> inefficient way I can imagine.
Agreed -- but that is a decision I assume they made for some reason. I will
propose your suggestion to the upstream developers, though :)
> Regardless, the PCRE_EXTRA_MARK flag may cause other side effects (memory
> overwrites if the mark pointer is invalid) so I would check thoroughly in
> the engine.
Thank you for all your help! I'll close this bug now.
--
You are receiving this mail because:
You are on the CC list for the bug.
