[pcre-dev] [Bug 1841] New: Pcre using a lot of cpu and time to match

https://bugs.exim.org/show_bug.cgi?id=1841 Bug ID: 1841 Summary: Pcre using a lot of cpu and time to match Product: PCRE Version: 8.34 Hardware: x86-64 OS: Windows Status: NEW Severity: bug

[pcre-dev] [Bug 1841] Pcre using a lot of cpu and time to match

https://bugs.exim.org/show_bug.cgi?id=1841 Philip Hazel changed: What|Removed |Added Resolution|--- |INVALID

[pcre-dev] [Bug 1847] New: invalid read / possible negative array index in pcre2test.c / extend_inputline()

https://bugs.exim.org/show_bug.cgi?id=1847 Bug ID: 1847 Summary: invalid read / possible negative array index in pcre2test.c / extend_inputline() Product: PCRE Version: 10.21 (PCRE2) Hardware: x86-64 OS:

[pcre-dev] [Bug 1845] Compile fails with Intel C++ compiler icpc

https://bugs.exim.org/show_bug.cgi?id=1845 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1681] CMake compiles PCRE dynamically even when set to static

https://bugs.exim.org/show_bug.cgi?id=1681 --- Comment #7 from Philip Hazel --- I barely understand CMake (as I said before) and I know nothing about MSVC or Windows (I live in a Linux world). If someone can provide yet another patch, I am happy to apply it - I can't test

[pcre-dev] [Bug 1849] clang 3.8 warnings from pcre2test.c

https://bugs.exim.org/show_bug.cgi?id=1849 j...@iki.fi changed: What|Removed |Added Priority|medium |low --- Comment #1 from j...@iki.fi --- Using

[pcre-dev] [Bug 1848] pcregrep outputs duplicate matches

https://bugs.exim.org/show_bug.cgi?id=1848 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1783] An issue exists in the callout function of PCRE that leads to heap-buffer-overflow when strlen() inside pchars(pcre_uint8 *p, int length, FILE *f) calculates length and it reads

https://bugs.exim.org/show_bug.cgi?id=1783 Brian Martin changed: What|Removed |Added CC|

[pcre-dev] [Bug 1780] Stack corruption from crafted pattern

https://bugs.exim.org/show_bug.cgi?id=1780 Brian Martin changed: What|Removed |Added CC|

[pcre-dev] [Bug 1777] Heap buffer overflow in main function of pcretest.c

https://bugs.exim.org/show_bug.cgi?id=1777 Brian Martin changed: What|Removed |Added CC|

[pcre-dev] [Bug 1777] Heap buffer overflow in main function of pcretest.c

https://bugs.exim.org/show_bug.cgi?id=1777 --- Comment #7 from Philip Hazel --- Yes. A committed patch always means it will be fixed in the next release. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at

[pcre-dev] [Bug 1783] An issue exists in the callout function of PCRE that leads to heap-buffer-overflow when strlen() inside pchars(pcre_uint8 *p, int length, FILE *f) calculates length and it reads

https://bugs.exim.org/show_bug.cgi?id=1783 --- Comment #3 from Philip Hazel --- Yes. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev

[pcre-dev] [Bug 1780] Stack corruption from crafted pattern

https://bugs.exim.org/show_bug.cgi?id=1780 --- Comment #5 from Philip Hazel --- Yes. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev

[pcre-dev] [Bug 1681] CMake compiles PCRE dynamically even when set to static

https://bugs.exim.org/show_bug.cgi?id=1681 --- Comment #10 from Chris Wilson --- Created attachment 897 --> https://bugs.exim.org/attachment.cgi?id=897=edit CMake patch to make the static runtime a separate option, independent of PCRE_STATIC OK, I understand now, thanks.

[pcre-dev] [Bug 1681] CMake compiles PCRE dynamically even when set to static

https://bugs.exim.org/show_bug.cgi?id=1681 --- Comment #9 from Orvid King --- The issue is that it's perfectly reasonable to want a static build linked against the dynamic runtime. Basically, the issue is that these are all perfectly valid: .lib /MT .lib /MD .dll /MD .exe

[pcre-dev] [Bug 1681] CMake compiles PCRE dynamically even when set to static

https://bugs.exim.org/show_bug.cgi?id=1681 --- Comment #13 from Philip Hazel --- I have applied and committed the second patch to both PCRE1 and PCRE2. For PCRE1, this is too late for 8.39, which was released 10 days ago, but it will be in the next release, whenever that

[pcre-dev] [Bug 1681] CMake compiles PCRE dynamically even when set to static

https://bugs.exim.org/show_bug.cgi?id=1681 --- Comment #12 from Orvid King --- The .exe forms don't matter in this particular case, as PCRE is a library rather than a program. (I'm ignoring the existence of the test programs and utils for the sake of simplicity) .lib /MT:

[pcre-dev] [Bug 1681] CMake compiles PCRE dynamically even when set to static

https://bugs.exim.org/show_bug.cgi?id=1681 --- Comment #11 from Roy Ivy III --- @Orvid King @Chris Wilson Please pardon my confusion, but, after the newest proposed patch, can either or both of you you spell out what CMake incantations build each of the five noted

[pcre-dev] [Bug 1763] Returning only first match in JIT

https://bugs.exim.org/show_bug.cgi?id=1763 Philip Hazel changed: What|Removed |Added Resolution|--- |INVALID

[pcre-dev] [Bug 1779] New: Segfault in preg_match PHP 7.0.2 (stack corruption)

https://bugs.exim.org/show_bug.cgi?id=1779 Bug ID: 1779 Summary: Segfault in preg_match PHP 7.0.2 (stack corruption) Product: PCRE Version: 8.37 Hardware: x86-64 OS: Linux Status: NEW Severity: security

[pcre-dev] [Bug 1779] Segfault in preg_match PHP 7.0.2 (stack corruption)

https://bugs.exim.org/show_bug.cgi?id=1779 Craig Young changed: What|Removed |Added Priority|medium |critical --- Comment #1 from

[pcre-dev] [Bug 1779] Segfault in preg_match PHP 7.0.2 (stack corruption)

https://bugs.exim.org/show_bug.cgi?id=1779 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1852] New: Large regex fails to compile, Limitation in pcre?

https://bugs.exim.org/show_bug.cgi?id=1852 Bug ID: 1852 Summary: Large regex fails to compile, Limitation in pcre? Product: PCRE Version: 8.34 Hardware: x86-64 OS: Windows Status: NEW Severity: bug

[pcre-dev] [Bug 1852] Large regex fails to compile, Limitation in pcre?

https://bugs.exim.org/show_bug.cgi?id=1852 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1791] ZDI-CAN-3542: New Vulnerability Report

https://bugs.exim.org/show_bug.cgi?id=1791 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1786] Possible Stack Corruption from crafted pattern

https://bugs.exim.org/show_bug.cgi?id=1786 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1783] An issue exists in the callout function of PCRE that leads to heap-buffer-overflow when strlen() inside pchars(pcre_uint8 *p, int length, FILE *f) calculates length and it reads

https://bugs.exim.org/show_bug.cgi?id=1783 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1774] Can't build JIT for Android ARM64

https://bugs.exim.org/show_bug.cgi?id=1774 --- Comment #2 from Tavian Barnes --- > - Why this is not working: > > #if (defined __has_builtin && __has_builtin(__builtin___clear_cache)) > > sljit_src/sljitConfigInternal.h:299:46: error: > missing binary operator

[pcre-dev] [Bug 1795] x64 Compiler warnings introduced in 10.21

https://bugs.exim.org/show_bug.cgi?id=1795 --- Comment #1 from Philip Hazel --- Thanks for the report. I do compile (using gcc) with as many warnings as I can, but different compilers do have different ideas about warnings. (No problem with the German; I know enough to

[pcre-dev] [Bug 1795] New: x64 Compiler warnings introduced in 10.21

https://bugs.exim.org/show_bug.cgi?id=1795 Bug ID: 1795 Summary: x64 Compiler warnings introduced in 10.21 Product: PCRE Version: 10.21 (PCRE2) Hardware: x86-64 OS: Windows Status: NEW Severity: bug

[pcre-dev] [Bug 1791] New: ZDI-CAN-3542: New Vulnerability Report

https://bugs.exim.org/show_bug.cgi?id=1791 Bug ID: 1791 Summary: ZDI-CAN-3542: New Vulnerability Report Product: PCRE Version: N/A Hardware: x86 OS: Windows Status: NEW Severity: bug Priority:

[pcre-dev] [Bug 1743] Invalid memory accesses in pcretest.c

https://bugs.exim.org/show_bug.cgi?id=1743 Philip Hazel changed: What|Removed |Added Resolution|--- |WONTFIX

[pcre-dev] [Bug 1759] pcreposix: REG_NOSUB incompatible with POSIX regex

https://bugs.exim.org/show_bug.cgi?id=1759 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1786] New: Possible Stack Corruption from crafted pattern

https://bugs.exim.org/show_bug.cgi?id=1786 Bug ID: 1786 Summary: Possible Stack Corruption from crafted pattern Product: PCRE Version: 10.21 (PCRE2) Hardware: x86-64 OS: Linux Status: NEW Severity:

[pcre-dev] [Bug 1774] Can't build JIT for Android ARM64

https://bugs.exim.org/show_bug.cgi?id=1774 Zoltan Herczeg changed: What|Removed |Added CC||hzmes...@freemail.hu ---

[pcre-dev] [Bug 1785] New: pcre version 8.38 - pcre_compile() exits with ERR23

https://bugs.exim.org/show_bug.cgi?id=1785 Bug ID: 1785 Summary: pcre version 8.38 - pcre_compile() exits with ERR23 Product: PCRE Version: 8.38 Hardware: x86-64 OS: Windows Status: NEW Severity: bug

[pcre-dev] [Bug 1785] pcre version 8.38 - pcre_compile() exits with ERR23

https://bugs.exim.org/show_bug.cgi?id=1785 --- Comment #1 from Philip Hazel --- What do you mean by "64-bit mode"? I have tried this on my 64-bit Linux box and I do not get any error. Did you set any PCRE options? What is the output of "pcretest -C"? (In other words, what

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 --- Comment #16 from Christian Schneider --- (In reply to Anatol Belski from comment #14) > I've just tested the repro program with vc14 x64 and see no issues. After > that I've tried the same prog with PCRE 8.35 and 8.38, but

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 --- Comment #14 from Anatol Belski --- I've just tested the repro program with vc14 x64 and see no issues. After that I've tried the same prog with PCRE 8.35 and 8.38, but strangely I don't see any issues there as well. Only the crash I

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 --- Comment #15 from Anatol Belski --- Tested with trunk first I mean. Thanks. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev

[pcre-dev] [Bug 1801] New: Test #18 fails

https://bugs.exim.org/show_bug.cgi?id=1801 Bug ID: 1801 Summary: Test #18 fails Product: PCRE Version: 10.21 (PCRE2) Hardware: x86 OS: Windows Status: NEW Severity: bug Priority: medium

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 --- Comment #12 from Zoltan Herczeg --- Thank you. It seems the bug is present in 8.38 and caused by a bad fast forward search (the original bug caused by a different issue). However, this part has been redesigned recently, and the

[pcre-dev] [Bug 1798] New: Regression in value reported by PCRE2_INFO_ALLOPTIONS wrt PCRE2_DUPNAMES

https://bugs.exim.org/show_bug.cgi?id=1798 Bug ID: 1798 Summary: Regression in value reported by PCRE2_INFO_ALLOPTIONS wrt PCRE2_DUPNAMES Product: PCRE Version: 10.21 (PCRE2) Hardware: x86-64 OS: Windows

[pcre-dev] [Bug 1801] Test #18 fails

https://bugs.exim.org/show_bug.cgi?id=1801 --- Comment #2 from Roy Ivy III --- Testing still fails, but it's close. "testout8\testoutput18": ``` /\[A]{100}**/expand,regerror_buffsize=31 Failed: POSIX code 4: ? * + invalid at offset 101 ** regerror() message

[pcre-dev] [Bug 1681] CMake compiles PCRE dynamically even when set to static

https://bugs.exim.org/show_bug.cgi?id=1681 --- Comment #3 from Chris Wilson --- Created attachment 867 --> https://bugs.exim.org/attachment.cgi?id=867=edit Updated patch as requested, using inline code, not from WebM OK, here is a patch that adds the extra configuration

[pcre-dev] [Bug 1801] Test #18 fails

https://bugs.exim.org/show_bug.cgi?id=1801 --- Comment #4 from Roy Ivy III --- Yes, that fixes it. To check on a bugged 'snprintf()' function, I added MSVC compilation to my build script (https://github.com/rivy/PCRE). And it does test successfully, lending credence to

[pcre-dev] [Bug 1801] Test #18 fails

https://bugs.exim.org/show_bug.cgi?id=1801 --- Comment #5 from Roy Ivy III --- So, it turns out that MinGW GCC uses the MSVC _snprintf() which does not conform to the C99 specification for snprintf(). Since at least VC6 (cl 12.00), MSVC has had _snprintf() which exhibits

[pcre-dev] [Bug 1801] Test #18 fails

https://bugs.exim.org/show_bug.cgi?id=1801 --- Comment #6 from Roy Ivy III --- I wanted to add that using "snprintf()" blocks compilation for MSVC compilers older than MSVC 14/2015 (cl 19.00). If you add: ``` #if defined(_MSC_VER) && (_MSC_VER < 1900) #define snprintf

[pcre-dev] [Bug 1681] CMake compiles PCRE dynamically even when set to static

https://bugs.exim.org/show_bug.cgi?id=1681 --- Comment #4 from Roy Ivy III --- This would be a great addition to PCRE2 as well. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 --- Comment #17 from Zoltan Herczeg --- I was able to reproduce the bug, but since the code changed anyway, I don't want to put too much effort to figure things out. -- You are receiving this mail because: You are on the CC list

[pcre-dev] [Bug 1777] Heap buffer overflow in main function of pcretest.c

https://bugs.exim.org/show_bug.cgi?id=1777 --- Comment #4 from Philip Hazel --- (In reply to Tomas Hoger from comment #3) > This is not the first \O1 issue recently. One was also fixed in 8.38/10. > Is there a reason to have pcretest use arbitrary ovector sizes (without

[pcre-dev] [Bug 1801] Test #18 fails

https://bugs.exim.org/show_bug.cgi?id=1801 --- Comment #7 from Philip Hazel --- (In reply to Roy Ivy III from comment #4) > One additional niggle, discovered when compiling with MSVC, is that MSVC > shows a warning for "src\pcre2test.c" being not "const-correct" @ lines

[pcre-dev] [Bug 1801] Test #18 fails

https://bugs.exim.org/show_bug.cgi?id=1801 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1777] Heap buffer overflow in main function of pcretest.c

https://bugs.exim.org/show_bug.cgi?id=1777 --- Comment #5 from Tomas Hoger --- Yes, it's understood pcretest is meant to provide functionality to test the lib, sometimes outside expected uses. A warning was suggested to (hopefully) stop more bugs in such incorrect library use

[pcre-dev] [Bug 1798] Regression in value reported by PCRE2_INFO_ALLOPTIONS wrt PCRE2_DUPNAMES

https://bugs.exim.org/show_bug.cgi?id=1798 Philip Hazel changed: What|Removed |Added Resolution|--- |INVALID

[pcre-dev] [Bug 1801] Test #18 fails

https://bugs.exim.org/show_bug.cgi?id=1801 --- Comment #1 from Philip Hazel --- Thanks for the report. From your output it would appear that the snprintf() function, which is now used in PCRE2's version of regerror(), behaves differently in your environment when the buffer

[pcre-dev] [Bug 1767] PCRE Library Heap Overflow Vulnerability

https://bugs.exim.org/show_bug.cgi?id=1767 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1777] Heap buffer overflow in main function of pcretest.c

https://bugs.exim.org/show_bug.cgi?id=1777 Philip Hazel changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1780] Stack corruption from crafted pattern

https://bugs.exim.org/show_bug.cgi?id=1780 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 Christian Schneider changed: What|Removed |Added CC||p...@cschneid.com ---

[pcre-dev] [Bug 1780] New: Stack corruption from crafted pattern

https://bugs.exim.org/show_bug.cgi?id=1780 Bug ID: 1780 Summary: Stack corruption from crafted pattern Product: PCRE Version: 8.38 Hardware: x86-64 OS: Linux Status: NEW Severity: security

[pcre-dev] [Bug 1780] Stack corruption from crafted pattern

https://bugs.exim.org/show_bug.cgi?id=1780 Craig Young changed: What|Removed |Added CC||cyo...@tripwire.com ---

[pcre-dev] [Bug 1780] Stack corruption from crafted pattern

https://bugs.exim.org/show_bug.cgi?id=1780 --- Comment #2 from Philip Hazel --- This bug is fixed in PCRE2: $ pcre2test ~/tmp/29.min PCRE2 version 10.20 2015-06-30 /\N(?(?C)0?!.)*/ Failed: error 128 at offset 4: assertion expected after (?( or (?(?C) I will, in due

[pcre-dev] [Bug 1795] x64 Compiler warnings introduced in 10.21

https://bugs.exim.org/show_bug.cgi?id=1795 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 Anatol Belski changed: What|Removed |Added CC||a...@php.net --- Comment #3 from

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 --- Comment #4 from Zoltan Herczeg --- Hi, I am sorry for not doing anything with this bug, it issue should likely be closed by now. Unfortunately Dmitry only provided a pattern without input, so it is hard to tell whether it is

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 --- Comment #5 from Anatol Belski --- Hi Zoltan, oh yes, there is a difference in these two. I was too concentrated on checking a crash that didn't compare. Here it is php -n -r 'ini_set("pcre.jit", 0); echo

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 --- Comment #6 from Anatol Belski --- Just a follow up on this. The previous output comes with PCRE 8.38 on Jessie. I've just retested on Windows, and there the output is "x°z" in both cases. Thanks. -- You are receiving this mail

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 --- Comment #7 from Anatol Belski --- Ohh no. Zoltan, I apologize the confusion. "x°z" it is on both Linux and Windows, so no difference. My test mistake by typing on console that seems somehow to have swallowed a part of the input.

[pcre-dev] [Bug 1189] JIT bug with lookbehind assertion.

https://bugs.exim.org/show_bug.cgi?id=1189 --- Comment #10 from Anatol Belski --- The actual replace code uses pcre_exec to match with the pattern yep, it's here http://lxr.php.net/xref/PHP_7_0/ext/pcre/php_pcre.c#1165 . I can confirm that the offsets are as you said {3,5}. I've

[pcre-dev] [Bug 1803] New: segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 Bug ID: 1803 Summary: segfault in pcre jit when running twig test suite (PHP7) Product: PCRE Version: 8.38 Hardware: x86 OS: Linux Status: NEW

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 Nish Aravamudan changed: What|Removed |Added Resolution|--- |INVALID

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 --- Comment #36 from Nish Aravamudan --- (In reply to Zoltan Herczeg from comment #33) > > I grabbed a lot of gdb output just now, trying to narrow down when > > size_offsets location gets trashed to 0. I noticed that

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 --- Comment #44 from Zoltan Herczeg --- > $62 = {flags = 115, study_data = 0x55d33610, match_limit = 100, > callout_data = 0x0, > tables = 0x21e , > match_limit_recursion = 10, mark = 0x7fff9288, >

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 --- Comment #34 from Nish Aravamudan --- (gdb) print _offsets $49 = (int *) 0x7fff9288 (gdb) watch *0x7fff9288 Hardware watchpoint 4: *0x7fff9288 Old value = 3 New value = 0 _pcre_jit_exec

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 --- Comment #40 from Nish Aravamudan --- (In reply to Zoltan Herczeg from comment #38) > I mean just print *extra_bump here: > > count = pcre_exec(re_bump, extra_bump, subject, > > so we can see all of its fields. (gdb)

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 --- Comment #38 from Zoltan Herczeg --- I mean just print *extra_bump here: count = pcre_exec(re_bump, extra_bump, subject, so we can see all of its fields. -- You are receiving this mail because: You are on the CC list for the

[pcre-dev] [Bug 1430] Request to spin up a new version of pcre with ppc64le support

https://bugs.exim.org/show_bug.cgi?id=1430 Zoltan Herczeg changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1243] enabling JIT on jailbroken iOS devices

https://bugs.exim.org/show_bug.cgi?id=1243 Zoltan Herczeg changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1357] Insufficient implementation of PCRE_CALL_CONVENTION

https://bugs.exim.org/show_bug.cgi?id=1357 Zoltan Herczeg changed: What|Removed |Added CC||hzmes...@freemail.hu

[pcre-dev] [Bug 1654] PCRE (JIT) does not build on WinCE / x86

https://bugs.exim.org/show_bug.cgi?id=1654 Zoltan Herczeg changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1423] Bad condition when optimizing character range checks

https://bugs.exim.org/show_bug.cgi?id=1423 Zoltan Herczeg changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1384] RunTest fails when PCRE is compiled with --enable-jit

https://bugs.exim.org/show_bug.cgi?id=1384 Zoltan Herczeg changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1174] allow passing of pcre_{malloc, free, stack_malloc, stack_free, callout} as parameters

https://bugs.exim.org/show_bug.cgi?id=1174 Zoltan Herczeg changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1428] cannot build on mingw32 (8.34)

https://bugs.exim.org/show_bug.cgi?id=1428 Zoltan Herczeg changed: What|Removed |Added Status|REOPENED|RESOLVED

[pcre-dev] [Bug 1774] Can't build JIT for Android ARM64

https://bugs.exim.org/show_bug.cgi?id=1774 Zoltan Herczeg changed: What|Removed |Added Status|RESOLVED|REOPENED

[pcre-dev] [Bug 1295] add 32-bit library

https://bugs.exim.org/show_bug.cgi?id=1295 Zoltan Herczeg changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

https://bugs.exim.org/show_bug.cgi?id=1642 Zoltan Herczeg changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1597] JIT compiling buffer overflow issue was fixed.

https://bugs.exim.org/show_bug.cgi?id=1597 Zoltan Herczeg changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1326] pcre-8.33-RC1 build on x86 fails @ "error: PIC register clobbered by '%ebx' in 'asm'"

https://bugs.exim.org/show_bug.cgi?id=1326 Zoltan Herczeg changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1208] Case folding in PCRE

https://bugs.exim.org/show_bug.cgi?id=1208 Zoltan Herczeg changed: What|Removed |Added Status|NEW |RESOLVED

[pcre-dev] [Bug 1180] Visual Studio 2010 x64 wanrings

https://bugs.exim.org/show_bug.cgi?id=1180 Zoltan Herczeg changed: What|Removed |Added Resolution|--- |FIXED

[pcre-dev] [Bug 1774] Can't build JIT for Android ARM64

https://bugs.exim.org/show_bug.cgi?id=1774 --- Comment #3 from Zoltan Herczeg --- I am very sorry it took a while for me to fix this: https://lists.exim.org/lurker/message/20160406.071510.a067ef1f.en.html

[pcre-dev] [Bug 1774] Can't build JIT for Android ARM64

https://bugs.exim.org/show_bug.cgi?id=1774 Tavian Barnes changed: What|Removed |Added Status|REOPENED|RESOLVED

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 --- Comment #21 from Zoltan Herczeg --- Another idea just came to my mind. It seems that all patterns are compiled by pcre_compile here: https://github.com/php/php-src/blob/master/ext/pcre/php_pcre.c#L433 Would it be possible to

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 --- Comment #29 from Zoltan Herczeg --- > I don't see any problem. So I'm not 100% sure it's this pattern in this > execution that is bad, but some state somewhere (could be php, could be > libpcre) is getting corrupted. I agree.

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 --- Comment #5 from Nish Aravamudan --- Two updates from my testing last night. 1) The twig testsuite is run using phpunit. phpunit has a parameter --process-isolation. When the tests are run with that parameter, the

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 --- Comment #13 from Zoltan Herczeg --- > (gdb) print last_match > $6 = 0x7fffed43e1fc "\303\237\343\201\224a" > (gdb) print [offsets[0]]-last_match > $7 = -2 That is likely incorrect. I think we soon find this bug. If I

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 --- Comment #17 from Zoltan Herczeg --- > 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 =

[pcre-dev] [Bug 1803] segfault in pcre jit when running twig test suite (PHP7)

https://bugs.exim.org/show_bug.cgi?id=1803 --- Comment #16 from Nish Aravamudan --- (In reply to Zoltan Herczeg from comment #15) > (In reply to Nish Aravamudan from comment #14) > > (gdb) break ext/pcre/php_pcre.c:1794 if strcmp(subject, > >

<    1   2   3   4   5   6   7   8   9   10   >