[pcre-dev] [Bug 1803] segfault in pcre jit when running twig…

トップ ページ
このメッセージを削除
著者: admin
日付:  
To: pcre-dev
題目: [pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)
https://bugs.exim.org/show_bug.cgi?id=1803

--- Comment #18 from Nish Aravamudan <nish.aravamudan@???> ---
(In reply to Zoltan Herczeg from comment #17)
> > 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.


I would expect that would be the pattern, based upon my understanding of twig.

> 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.


So I attempted to do this a few times, but the failing &pce->re value kept
changing between runs. Is that expected? That made the write watchpoint fail to
trip. Any advice? Agreed we need to figure out what the pattern actually is.

--
You are receiving this mail because:
You are on the CC list for the bug.