On Fri, May 14, 2021 at 01:36:12PM -0000, Stephane Chazelas wrote:
>The important backtrace in there is the one from thread 11:
>
>#0 0x00007fb288428474 in read () from /lib/x86_64-linux-gnu/libpthread.so.0
>No symbol table info available.
>#1 0x00007fb2890c4518 in ?? () from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
>No symbol table info available.
>#2 0x00007fb287895848 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.30
>No symbol table info available.
This is a valid issue, but are we certain it's the same one? The
reporter talked about sched_yield and their backtraces included several
threads of back_monitor waiting on some kind of lock.
Right. I'm not confident I can backport that correctly, so I'd feel
safer just doing the revert. However, sssd should also be tested, to
ensure the version in bionic isn't affected by ITS#9210
(https://bugs.openldap.org/show_bug.cgi?id=9210).
On Fri, May 14, 2021 at 01:36:12PM -0000, Stephane Chazelas wrote: 64-linux- gnu/libpthread. so.0 x86_64- linux-gnu/ liblber- 2.4.so. 2 x86_64- linux-gnu/ libgnutls. so.30
>The important backtrace in there is the one from thread 11:
>
>#0 0x00007fb288428474 in read () from /lib/x86_
>No symbol table info available.
>#1 0x00007fb2890c4518 in ?? () from /usr/lib/
>No symbol table info available.
>#2 0x00007fb287895848 in ?? () from /usr/lib/
>No symbol table info available.
This is a valid issue, but are we certain it's the same one? The
reporter talked about sched_yield and their backtraces included several
threads of back_monitor waiting on some kind of lock.
>https:/ /bugs.openldap. org/show_ bug.cgi? id=8650# c12 explains that it's /github. com/openldap/ openldap/ commit/ 7b5181da8cdd47a 13041f9ee36fa95 90a0fa6e48 /github. com/openldap/ openldap/ commit/ 4c1ab16ade18a25 3dd81df7e6eced4 d920ac6a8e
>https:/
>that is responsible for the issue.
>
>https:/
>reverted that commit, but that one did not make it into bionic.
Indeed. :( I didn't notice this went unfixed in an LTS, I'm sorry for
missing that.
>So cherry picking /github. com/openldap/ openldap/ commit/ 4c1ab16ade18a25 3dd81df7e6eced4 d920ac6a8e
>https:/
>should fix it.
In this version it's a Debian patch, so probably just remove the
offending patch from d/patches, rather than import the revert?
On Fri, May 14, 2021 at 02:18:47PM -0000, Stephane Chazelas wrote: /github. com/openldap/ openldap/ commit/ 735e1ab14bb0553 44b4e767a216aa4 10aa7d1503
>Yes,
>https:/
>can't be directly applied there. There have been other changes in
>between in that section including changes in API, so it would take more
>effort to backport that fix.
Right. I'm not confident I can backport that correctly, so I'd feel /bugs.openldap. org/show_ bug.cgi? id=9210).
safer just doing the revert. However, sssd should also be tested, to
ensure the version in bionic isn't affected by ITS#9210
(https:/
COMPLETELY UNTESTED debdiff attached.