I would highly recommend reviewing the information at https://corelight.blog/2021/05/13/tracking-down-a-glibc-regression/ as they did a lot of work tracking down exactly what happened and how. There is a newer commit to glibc which fixes this problem, but it does not appear to be in the version that Gentoo is currently shipping (2.33-r1). I'm not sure what would need to be done to correct this as I am not a Gentoo maintainer, but perhaps there could be a patch added to the ebuild which implements the fix in https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=9d7c5cc38e58fb0923e88901f87174a511b61552 Reproducible: Always Steps to Reproduce: I was able to reproduce the problem consistently with an application named plotman (a python application), but I'm not sure how feasible it is to ask people to set that up. So far I haven't found any other applications (yet) that are affected.
Thanks for the report and bringing this to our attention.
(In reply to Chris Jowett from comment #0) > I would highly recommend reviewing the information at > https://corelight.blog/2021/05/13/tracking-down-a-glibc-regression/ as they > did a lot of work tracking down exactly what happened and how. > > There is a newer commit to glibc which fixes this problem, but it does not > appear to be in the version that Gentoo is currently shipping (2.33-r1). > It's a bit late here but are you sure? I see https://gitweb.gentoo.org/fork/glibc.git/commit/?h=gentoo/2.33&id=1fafc22294c5b0398c732f8e79a586c020021557 which was before we tagged 2.33-4 of our patchset. glibc-2.33-r1 is using PATCH_VER=4 which corresponds to that tag.
I could be wrong, but what I am seeing in strace looks an awful lot like what is spoken about there. I guess it could be a similar performance problem with some element of python perhaps.
Created attachment 722140 [details] `ebuild glibc-2.33-r1.ebuild clean prepare` output Hm, it does seem to be included: * 0031-tst-Provide-test-for-select.patch ... [ ok ] * 0032-misc-Fix-tst-select-timeout-handling-BZ-27648.patch ... [ ok ] * 0033-libsupport-Add-support_select_modifies_timeout.patch ... [ ok ] * 0034-libsupport-Add-support_select_normalizes_timeout.patch ... [ ok ] * 0035-linux-Normalize-and-return-timeout-on-select-BZ-2765.patch ... [ ok ] * 0036-linux-always-update-select-timeout-BZ-27706.patch ... [ ok ] * 0037-tunables-Fix-comparison-of-tunable-values.patch ... [ ok ] * 0038-support-Typo-and-formatting-fixes.patch ... [ ok ] * 0039-support-Pass-environ-to-child-process.patch ... [ ok ] * 0040-support-Add-capability-to-fork-an-sgid-child.patch ... [ ok ] * 0041-tst-env-setuid-Use-support_capture_subprogram_self_s.patch ... [ ok ]
well, I would have tested with an older version of glibc, which would have verified for sure if I was suffering some kind of a regression, but everything I am reading in the ebuild warning as well as on the gentoo wiki basically says that if I do that I have a pretty high chance of breaking my system.
(In reply to Chris Jowett from comment #5) > well, I would have tested with an older version of glibc, which would have > verified for sure if I was suffering some kind of a regression, but > everything I am reading in the ebuild warning as well as on the gentoo wiki > basically says that if I do that I have a pretty high chance of breaking my > system. No, I understand of course. Could you: - give some instructions on how to reproduce? (it's okay if it's complicated, it is what it is) - share the strace output - share emerge --info?
I'll try and get you that information in the morning, thanks!
(In reply to Chris Jowett from comment #0) > I would highly recommend reviewing the information at > https://corelight.blog/2021/05/13/tracking-down-a-glibc-regression/ as they > did a lot of work tracking down exactly what happened and how. > > There is a newer commit to glibc which fixes this problem, but it does not > appear to be in the version that Gentoo is currently shipping (2.33-r1). > > I'm not sure what would need to be done to correct this as I am not a Gentoo > maintainer, but perhaps there could be a patch added to the ebuild which > implements the fix in > https://sourceware.org/git/?p=glibc.git;a=commitdiff; > h=9d7c5cc38e58fb0923e88901f87174a511b61552 > > Reproducible: Always Your link has a minimal test, it does not fail for me on glibc-2.33-r1: $ gcc a.c -o a && ./a tv before: 4.000000 Data is available now. tv after : 1.999674 select: OK > Steps to Reproduce: > I was able to reproduce the problem consistently with an application named > plotman (a python application), but I'm not sure how feasible it is to ask > people to set that up. So far I haven't found any other applications (yet) > that are affected. Can you share exact steps to execute to observe the change? Is it a filesystem-heavy application? There is a small chance that #773436 might be responsible (easy to check by reverting /etc/nsswitch.conf locally).
So I had an unplanned change of events and I don't (and won't) have access to that Gentoo system for quite a while. That said, I was able to also replicate the issue in Ubuntu 21.04, so I don't think this is a Gentoo specific problem. We can go ahead and close this ticket
(In reply to Chris Jowett from comment #9) > So I had an unplanned change of events and I don't (and won't) have access > to that Gentoo system for quite a while. That said, I was able to also > replicate the issue in Ubuntu 21.04, so I don't think this is a Gentoo > specific problem. > > We can go ahead and close this ticket That's a good bit of information. Thank you!
