Back to bug 1888660
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Red Hat Bugzilla | 2020-10-15 12:56:46 UTC | Pool ID | sst_platform_tools_rhel_8 | |
| Florian Weimer | 2020-10-15 14:17:17 UTC | Keywords | Bugfix, Triaged | |
| Summary | hang at pthread_atfork | glibc: pthread_atfork handlers that call pthread_atfork deadlock | ||
| Red Hat One Jira (issues.redhat.com) | 2020-10-31 21:40:16 UTC | Link ID | Red Hat Issue Tracker - Private RHELPLAN-57105 | |
| Vikramsingh Patil | 2020-11-25 13:51:40 UTC | CC | vikpatil | |
| Florian Weimer | 2020-12-11 15:26:44 UTC | Link ID | Sourceware 27054 | |
| Florian Weimer | 2020-12-11 15:27:09 UTC | Flags | needinfo?(vikpatil) | |
| Vikramsingh Patil | 2021-02-26 03:31:10 UTC | Flags | needinfo?(vikpatil) | |
| Pavel Najman | 2021-09-17 12:24:26 UTC | Pool ID | sst_platform_tools_rhel_8 | sst_pt_pcp_rhel_8 |
| Pavel Najman | 2021-09-17 12:34:06 UTC | Pool ID | sst_pt_pcp_rhel_8 | sst_pt_gcc_glibc_rhel_8 |
| Carlos O'Donell | 2022-02-09 14:36:02 UTC | Assignee | glibc-bugzilla | ashankar |
| Arjun Shankar | 2022-05-31 14:55:28 UTC | Status | NEW | ASSIGNED |
| Keywords | Patch | |||
| Martin Coufal | 2022-05-31 15:07:10 UTC | CC | mcoufal, skolosov | |
| QA Contact | qe-baseos-tools-bugs | mcoufal | ||
| Carlos O'Donell | 2022-06-06 16:04:25 UTC | Doc Type | If docs needed, set a value | Bug Fix |
| Arjun Shankar | 2022-06-13 14:21:57 UTC | Fixed In Version | glibc-2.28-206.el8 | |
| Status | ASSIGNED | MODIFIED | ||
| errata-xmlrpc | 2022-06-15 08:48:45 UTC | Status | MODIFIED | ON_QA |
| Martin Coufal | 2022-06-15 11:04:12 UTC | Deadline | 2022-07-04 | |
| Carlos O'Donell | 2022-06-16 13:23:19 UTC | Doc Text | Cause: A defect in the processing of pthread_atfork handler execution. Consequence: Caused a change in the order of execution of handlers which could lead to application hangs. Fix: The pthread_atfork handler execution has been simplified Result: Applications should no longer experience hangs when registering or executing registered handlers. |
|
| Martin Coufal | 2022-06-22 09:18:59 UTC | Status | ON_QA | VERIFIED |
| Jacob Taylor Valdez | 2022-07-12 07:07:20 UTC | Docs Contact | jvaldez | |
| CC | jvaldez | |||
| Doc Text | Cause: A defect in the processing of pthread_atfork handler execution. Consequence: Caused a change in the order of execution of handlers which could lead to application hangs. Fix: The pthread_atfork handler execution has been simplified Result: Applications should no longer experience hangs when registering or executing registered handlers. | .`pthread_atfork handler execution no longer causes applications hangs Previously, a defect in the processing of `pthread_atfork` handlers caused a change in the order that handlers were executed in and resulted in application hangs. The bug has been fixed and, as a result, applications should no longer experience hangs when registering or executing registered handlers. | ||
| Flags | needinfo?(ashankar) | |||
| Florian Weimer | 2022-07-12 07:17:04 UTC | Flags | needinfo?(ashankar) | |
| Jacob Taylor Valdez | 2022-07-12 07:33:09 UTC | Flags | needinfo?(fweimer) | |
| Doc Text | .`pthread_atfork handler execution no longer causes applications hangs Previously, a defect in the processing of `pthread_atfork` handlers caused a change in the order that handlers were executed in and resulted in application hangs. The bug has been fixed and, as a result, applications should no longer experience hangs when registering or executing registered handlers. | .Applications no longer deadlock when invoking `pthread_atfork` or `dclose` from fork handler callbacks Previously, `pthread_atfork` handler callbacks were invoked while `glibc` had acquired an internal lock. As a result, registering fork handlers or calling `dclose` from a fork handler could deadlock applications. A different synchronization mechanism is now used to protect internal data structures while fork handlers are running. As a result, applications no longer deadlock when invoking `pthread_atfork` or `dclose` from fork handler callbacks. |
||
| Florian Weimer | 2022-07-12 07:46:14 UTC | Flags | needinfo?(fweimer) | |
| Jacob Taylor Valdez | 2022-09-07 11:25:52 UTC | Doc Text | .Applications no longer deadlock when invoking `pthread_atfork` or `dclose` from fork handler callbacks Previously, `pthread_atfork` handler callbacks were invoked while `glibc` had acquired an internal lock. As a result, registering fork handlers or calling `dclose` from a fork handler could deadlock applications. A different synchronization mechanism is now used to protect internal data structures while fork handlers are running. As a result, applications no longer deadlock when invoking `pthread_atfork` or `dclose` from fork handler callbacks. | .Applications no longer deadlock when invoking `pthread_atfork` or `dclose` from fork handler callbacks Previously, applications invoked `pthread_atfork` handler callbacks while `glibc` had acquired an internal lock. As a result, registering fork handlers or calling `dclose` from a fork handler could deadlock applications. A different synchronization mechanism is now used to protect internal data structures while fork handlers are running. As a result, applications no longer deadlock when invoking `pthread_atfork` or `dclose` from fork handler callbacks. |
| errata-xmlrpc | 2022-11-08 00:18:34 UTC | Status | VERIFIED | RELEASE_PENDING |
| errata-xmlrpc | 2022-11-08 10:43:11 UTC | Resolution | --- | ERRATA |
| Status | RELEASE_PENDING | CLOSED | ||
| Last Closed | 2022-11-08 10:43:11 UTC | |||
| errata-xmlrpc | 2022-11-08 10:43:28 UTC | Link ID | Red Hat Product Errata RHBA-2022:7684 | |
| Mark O'Brien | 2023-07-18 14:30:35 UTC | Pool ID | sst_pt_glibc_rhel_8 | sst_pt_libraries_rhel_8 |
Back to bug 1888660