Bug 1938977

SSSD already supports PCRE2 library. It is just matter of packaging.

But PCRE is still the default in ./configure. Maybe it is the time to reverse the condition and prefer PCRE2 over PCRE.

Tomas

Hi,

I think an easy fix for the time being would be to replace 'BuildRequires: pcre-devel' with 'BuildRequires: pcre2-devel' (and hope that pcre-devel is not installed in the build environment by other means). However, given that (from the Red Hat perspective) only RHEL-6 does not provide pcre2 and there are no plan to make a recent version of SSSD available on this platform, I think we can deprecate pcre1 support from SSSD upstream completely in the next major release and remove it in the following one.

bye,
Sumit

Hi Petr,

while running our test-suite with pcre2, I run into following issue reported by Valgrind:
```
==18073== 316 bytes in 1 blocks are possibly lost in loss record 158 of 195
==18073==    at 0x483880B: malloc (vg_replace_malloc.c:309)
==18073==    by 0x5932151: pcre2_compile_8 (in /usr/lib64/libpcre2-8.so.0.9.0)
```

do you have any idea what could be a reason?
This happens in several tests and it's always 316 bytes.

`pcre2_code_free()` should be executed, is this enough?
Or is this a "known issues"?

(In reply to Alexey Tikhonov from comment #3)
> while running our test-suite with pcre2, I run into following issue reported
> by Valgrind:
> ```
> ==18073== 316 bytes in 1 blocks are possibly lost in loss record 158 of 195
> ==18073==    at 0x483880B: malloc (vg_replace_malloc.c:309)
> ==18073==    by 0x5932151: pcre2_compile_8 (in
> /usr/lib64/libpcre2-8.so.0.9.0)
> ```
> 
> do you have any idea what could be a reason?
> This happens in several tests and it's always 316 bytes.
> 
> `pcre2_code_free()` should be executed, is this enough?
> Or is this a "known issues"?

I'm not aware about any memory leak in pcre2. Can you show me your code including
a pattern and the options passed to pcre2_compile()? In general, once you don't
need the pcre2_code structure, you should free it with pcre2_code_free().

Well, 316 bytes corresponds to the pattern (and perhaps options) used:
```
"(((?P<domain>[^\\\\]+)\\\\(?P<name>.+$))|" \
"((?P<name>[^@]+)@(?P<domain>.+$))|" \
"(^(?P<name>[^@\\\\]+)$))";
```

But I was unable to reproduce an issue with a small test.
Seems something wrong with usage in sssd code.
I added a patch with a fix of potential mem leak to https://github.com/SSSD/sssd/pull/5593, but so far not sure if it was a cause...

Sorted out. PR is ready for review upstream.

Pushed PR: https://github.com/SSSD/sssd/pull/5593

* `master`
    * f2bcf74c43a682897e586eeb775c4bfedd95bafa - sssd.supp: suppress false positive valgrind warning about 'pcre2_code' ptr
    * 0fbe5af1f1e0b82cd36a8178e58d79b7dc357ab6 - util/regexp: regular talloc d-tor shouldn't fail
    * 9aa6fb34bea891e0385a9fc77f0181d01984c212 - tests/test_nested_groups: mem leak fixed
    * 31bcb6f032c326d62fb7ac5efcf2ff55c9acbe04 - tests/test_dp_opts: mem leak fixed
    * 519d943424ee744ecf7418df6bf6f0688a7d9099 - util/regexp: local functions shall be static
    * cbfccb173d1cfa631350778abbee82bca1fbc296 - BUILD: prefer PCRE2 over PCRE