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.
Original-patch-by: David Coppa [off-list ref]
Signed-off-by: Rene Scharfe <redacted>
---
t/t4062-diff-pickaxe.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t4062-diff-pickaxe.sh b/t/t4062-diff-pickaxe.sh
index 7c4903f497..c16e5af6fa 100755
--- a/t/t4062-diff-pickaxe.sh
+++ b/t/t4062-diff-pickaxe.sh
@@ -15,7 +15,7 @@ test_expect_success setup '
git commit -m "A 4k file"
'
test_expect_success '-G matches' '
- git diff --name-only -G "^0{4096}$" HEAD^ >out &&
+ git diff --name-only -G0 HEAD^ >out &&
test 4096-zeroes.txt = "$(cat out)"
'
--
2.14.0
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.
Maybe simply disable the test on OpenBSD instead? Or guard the {4096}
behind the MINGW prereq.
Ciao,
Dscho
Am 08.08.2017 um 16:49 schrieb Johannes Schindelin:
Hi René,
On Tue, 8 Aug 2017, René Scharfe wrote:
quoted
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é