https://bugs.exim.org/show_bug.cgi?id=1803
--- Comment #17 from Zoltan Herczeg <hzmester@???> ---
> Neither am I :) I appreciate your help!
Me too. And you are good at gdb, and that is rare :)
It seems we really get an offset pair before start_offset:
> (gdb) print start_offset
> $62 = 4
> (gdb) print offsets[0]
> $66 = 2
> (gdb) print offsets[1]
> $67 = 4
It is not impossible, a pattern like this can do that:
/(?<=\K.)/
But such patterns are rare.
Do you know what is the pattern here:
{{ baz|split('')|join('-') }}
An empty string? But that cannot match from 2-4.
And there is one more thing, the interpreters fills the offset[0] and [1] with
-1 in case of a failed match, but JIT does not do it. It can be a problem if
the application expects the former behavior, but that code does not seem to
rely on this.
However, this part somehow contradicts to this:
> (gdb) print offsets[0]
> $52 = -1
> (gdb) print offsets[1]
> $53 = -1
Anyway, I think we need to figure out which pattern causes the problem. The
pce->re member is set somewhere, you could capture that with a write
watchpoint:
p &pce->re
-> prints the absolute address
watch *(long*)address
rerun the application again with r.
You might capture some unwanted breakpoint hits (sometimes thousands :) ), but
just set a big ignore count to the watchpoint:
ignore 1 100000
When the crash happens type "info breakpoints" and check the hit count. Set the
ignore count just one (or two) below to that number and rerun the application
again. This time gdb will stop where the pattern is compiled (since that is the
last write to this address), and just check the pattern string. Please send it
to me.
--
You are receiving this mail because:
You are on the CC list for the bug.
