We've run into this bug with .NET Core garbage collector. It could lock up without warning. With the patch we were not able to reproduce the issue. Furthermore we've tried to stress test (to increase the chance of issue happening) to confirm the issue is fixed, and we didn't notice any slowdowns.
In our application under stresstest IO eventually becomes bottleneck (when OS runs out of memory and begins to dump data into mmap file - we use LMDB), but CPU consumption is constantly 50%+ and initially 70%+. When the system gets lower on memory GC threads wake up more frequently too. At the same time we tested on Ubuntu 16.04 (which is on glibc prior to the bug being introduced). We didn't see any difference in speed between app running on 16.04 and on 20.10 with the patch. We just measured speed of data processing, which fluctuates a little bit constantly due to a number of reasons. This is of course not a stress test of the lock itself, but at least it's an example of a real-world application and not seeing any easily noticeable effect on speed in our case. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899800 Title: Runtime deadlock: pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1899800/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
