Bug#755439: pcre3: DFA matching behaviour changed, breaking glib2.0 tests
tags 755439 + pending thanks On Mon, 28 Jul 2014 at 11:17:54 +0100, Simon McVittie wrote: I would really appreciate opinions from GLib maintainers on which solution to the DFA-matching thing is most correct, and whether the specific patches I sent upstream are OK. I have committed these changes to the unstable branch. If you don't want me (or some other team member) to upload them, speak now. If you *do* want me (or some other team member) to upload them, please comment on the upstream GLib bug and say the changes look good to you. https://bugzilla.gnome.org/show_bug.cgi?id=733325 If I don't hear anything either way I will upload what's in svn at some point. These tests pass, but I get a failure in an unrelated test (opening another bug now). One FTBFS was fixed by an upstream patch from the 2.41 branch, I can't reproduce the other. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755439: pcre3: DFA matching behaviour changed, breaking glib2.0 tests
tags 755439 + patch upstream thanks On Mon, 21 Jul 2014 at 10:17:09 +0100, Simon McVittie wrote: The remaining failures seem to be an intentional behaviour change in PCRE. I don't know whether the correct resolution is adapt GLib or partially revert the change in PCRE so I'm assigning this bug to both for now. I would really appreciate opinions from GLib maintainers on which solution to the DFA-matching thing is most correct, and whether the specific patches I sent upstream are OK. See https://bugzilla.gnome.org/show_bug.cgi?id=733325#c14 (and please take any positive or negative feedback upstream). svn diff for Debian's glib2.0 packaging attached. These tests pass, but I get a failure in an unrelated test (opening another bug now). Thanks, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755439: pcre3: DFA matching behaviour changed, breaking glib2.0 tests
On Mon, 21 Jul 2014 at 10:17:09 +0100, Simon McVittie wrote: The remaining failures seem to be an intentional behaviour change in PCRE. The attached was enough for GLib git master when I tried it yesterday. However, I'm getting an additional test failure now, building against my planned pcre3 NMU (which it looks as though the maintainer might upload now): # random seed: R02S8c9eb61b4add98149bfeeb19d0c7c029 # Start of regex tests ok 1 /regex/properties PASS: regex 1 /regex/properties ok 2 /regex/class PASS: regex 2 /regex/class ok 3 /regex/lookahead PASS: regex 3 /regex/lookahead ok 4 /regex/lookbehind PASS: regex 4 /regex/lookbehind # ERROR:/«PKGBUILDDIR»/./glib/tests/regex.c:1693:test_subpattern: assertion failed: (res) ERROR: regex - missing test plan ERROR: regex - exited with status 134 (terminated by signal 6?) S Index: debian/changelog === --- debian/changelog (revision 42085) +++ debian/changelog (working copy) @@ -13,6 +13,17 @@ * Use the default compiler on sparc, since it's already 4.7. Closes: #751313. + [ Simon McVittie ] + * Adapt for system pcre3/1:8.35 (Closes: #755439): +- a PCRE 8.31 bug in case-insensitivity has been fixed, so do not assert + bug-for-bug compatibility with 8.31 +- named match groups' names cannot start with a digit any more, so + (?P1.) is no longer allowed; do not assert that it is +- turn off a new optimization that would reduce the result set when called + from g_match_all(_full), to preserve existing functionality + * Build-depend on pcre3/1:8.35 so that the new optimization is +known to be turned off in the built binaries + -- Emilio Pozuelo Monfort po...@debian.org Mon, 05 May 2014 11:50:10 +0200 glib2.0 (2.40.0-3) unstable; urgency=medium Index: debian/control.in === --- debian/control.in (revision 42085) +++ debian/control.in (working copy) @@ -12,7 +12,7 @@ gnome-pkg-tools (= 0.11), dpkg-dev (= 1.16.0), libelfg0-dev (= 0.8.12), - libpcre3-dev (= 1:8.31), + libpcre3-dev (= 1:8.35), desktop-file-utils, gtk-doc-tools (= 1.20), libselinux1-dev [linux-any], Index: debian/patches/0001-regex-test-do-not-assert-that-system-PCRE-still-has-.patch === --- debian/patches/0001-regex-test-do-not-assert-that-system-PCRE-still-has-.patch (revision 0) +++ debian/patches/0001-regex-test-do-not-assert-that-system-PCRE-still-has-.patch (working copy) @@ -0,0 +1,36 @@ +From 8f0620d6304f5f2c386285f645b10409aa17e86e Mon Sep 17 00:00:00 2001 +From: Simon McVittie simon.mcvit...@collabora.co.uk +Date: Sun, 20 Jul 2014 19:33:59 +0100 +Subject: [PATCH 1/3] regex test: do not assert that system PCRE still has an + 8.31 bug + +This was fixed in 8.32. + +Bug: https://bugzilla.gnome.org/show_bug.cgi?id=733325 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755439 +Forwarded: yes +--- + glib/tests/regex.c | 6 +- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/glib/tests/regex.c b/glib/tests/regex.c +index 833e585..95b2360 100644 +--- a/glib/tests/regex.c b/glib/tests/regex.c +@@ -2446,8 +2446,12 @@ main (int argc, char *argv[]) + /* Test that othercasing in our pcre/glib integration is bug-for-bug compatible +* with pcre's internal tables. Bug #678273 */ + TEST_MATCH([DŽ], G_REGEX_CASELESS, 0, DŽ, -1, 0, 0, TRUE); +- TEST_MATCH([DŽ], G_REGEX_CASELESS, 0, Dž, -1, 0, 0, FALSE); + TEST_MATCH([DŽ], G_REGEX_CASELESS, 0, dž, -1, 0, 0, TRUE); ++#ifndef USE_SYSTEM_PCRE ++ /* This is a bug, which was fixed in 8.32. A system pcre might ++ * be that version or newer, so we cannot assert that it has this bug. */ ++ TEST_MATCH([DŽ], G_REGEX_CASELESS, 0, Dž, -1, 0, 0, FALSE); ++#endif + + /* TEST_MATCH_NEXT#(pattern, string, string_len, start_position, ...) */ + TEST_MATCH_NEXT0(a, x, -1, 0); +-- +2.0.1 + Index: debian/patches/0002-regex-test-do-not-assert-that-system-PCRE-allows-P-1.patch === --- debian/patches/0002-regex-test-do-not-assert-that-system-PCRE-allows-P-1.patch (revision 0) +++ debian/patches/0002-regex-test-do-not-assert-that-system-PCRE-allows-P-1.patch (working copy) @@ -0,0 +1,34 @@ +From 666aeffde7809927741fdf42bab611e4e73117af Mon Sep 17 00:00:00 2001 +From: Simon McVittie simon.mcvit...@collabora.co.uk +Date: Sun, 20 Jul 2014 19:34:54 +0100 +Subject: [PATCH 2/3] regex test: do not assert that system PCRE allows + (?P1) + +Perl = 5.18, and PCRE = 8.34, disallow this. + +Bug: https://bugzilla.gnome.org/show_bug.cgi?id=733325 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755439 +Forwarded: yes +--- + glib/tests/regex.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git
Bug#755439: pcre3: DFA matching behaviour changed, breaking glib2.0 tests
On 22/07/14 10:56, Simon McVittie wrote: The attached was enough for GLib git master when I tried it yesterday. However, I'm getting an additional test failure now [...] # ERROR:/«PKGBUILDDIR»/./glib/tests/regex.c:1693:test_subpattern: assertion failed: (res) This is because my patch involving PCRE_NO_AUTO_POSSESS is incorrect. See the upstream GLib bug. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755439: pcre3: DFA matching behaviour changed, breaking glib2.0 tests
retitle 755439 pcre3: DFA matching behaviour changed, breaking glib2.0 tests
reassign 755439 libpcre3,glib2.0
found 755439 pcre3/8.35-2,glib2.0/2.40.0-3
forwarded 755439
http://bugs.exim.org/show_bug.cgi?id=1504,https://bugzilla.gnome.org/show_bug.cgi?id=733325
severity 755439 serious
thanks
On Sun, 20 Jul 2014 at 20:42:05 +0100, Simon McVittie wrote:
The GLib tests are going to fail with PCRE 8.35, see referenced
upstream bug. Some of the failures are clearly spurious and can be
patched out, but some look like a genuine bug, either in GLib or PCRE
(my guess would be PCRE but I'm not sure).
The remaining failures seem to be an intentional behaviour change in PCRE.
I don't know whether the correct resolution is adapt GLib or partially
revert the change in PCRE so I'm assigning this bug to both for now.
This should maybe be Severity: serious
The regex test reliably fails, which will already cause FTBFS in glib2.0
if it is rebuilt in today's amd64 unstable, so yes I think it should.
but it'd probably be better with a test case that only uses PCRE API
first
Attached, and also sent upstream to the PCRE and GLib bug-trackers.
I have also sent potential fixes for GLib upstream to the GLib bug-tracker,
but I'm not going to copy them to this bug until there's some sort of
consensus how many of these issues are GLib bugs and how many are PCRE bugs.
S
/* gcc -odfa -lpcre dfa.c */
#include assert.h
#include pcre.h
int
main (void)
{
int errcode;
const char *errmsg;
int erroffset;
pcre *re;
int done;
int matches;
/* should be plenty */
int n_offsets = 1024;
int offsets[1024] = { 0 };
int n_workspace = 1024;
int workspace[1024] = { 0 };
re = pcre_compile2 (a+, 0, errcode, errmsg, erroffset, NULL);
assert (re != NULL);
matches = pcre_dfa_exec (re, NULL,
aaa, 3, 0, 0, offsets, n_offsets,
workspace, n_workspace);
assert (matches != PCRE_ERROR_DFA_WSSIZE);
assert (matches != 0);
assert (matches = PCRE_ERROR_NOMATCH || matches == PCRE_ERROR_PARTIAL);
assert (offsets[0] == 0);
assert (offsets[1] == 3);
assert (offsets[2] == 0);
assert (offsets[3] == 2);
assert (offsets[4] == 0);
assert (offsets[5] == 1);
assert (matches == 3);
return 0;
}
