Am 08.08.2017 um 16:49 schrieb Johannes Schindelin:
> Hi René,
>
> On Tue, 8 Aug 2017, René Scharfe wrote:
>
>> OpenBSD's regex library has a repetition limit (RE_DUP_MAX) of 255.
>> That's the minimum acceptable value according to POSIX. In t4062 we use
>> 4096 repetitions in the test "-G matches", though, causing it to fail.
>>
>> Do the same as the test "-S --pickaxe-regex" in the same file and search
>> for a single zero instead. That still suffices to trigger the buffer
>> overrun in older versions (checked with b7d36ffca02^ and --valgrind on
>> Linux), simplifies the test a bit, and avoids exceeding OpenBSD's limit.
>
> I am afraid not. The 4096 is precisely the page size required to trigger
> the bug on Windows against which this regression test tries to safeguard.
Checked with b7d36ffca02^ on MinGW now as well and found that it
segfaults with the proposed change ten out of ten times.
You get different results? How is that possible? The search string is
NUL-terminated in each case, while the point of the test is that the
file contents isn't, right?
> Maybe simply disable the test on OpenBSD instead? Or guard the {4096}
> behind the MINGW prereq.
It's easy to build a long search string with two repetitions or by using
a longer string as the base, if necessary. But first we need to find out
why regexec() doesn't overflow in your case. My build uses the version
from compat/. Why would it stop before reaching a NUL? That sounds like
a different and serious bug.
Thanks,
René
