unw_init_local is documented to be async-signal safe but calls pthread_mutex_lock
Maintainer antworten meist innerhalb von 4 Tagen
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 18/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- c
- Bereich
- operating-systems
Rechercherichtung
Start from unw_init_local and trace the one-time initialization path it calls, where pthread_mutex_lock is taken; the issue does not name the source files, so search for that call. Done means either the lock is kept off the async-signal-safe path or the required pre-initialization is documented, and the maintainers agree which. The thread has been idle for about 578 days with no decision, so confirm interest before investing time.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
While unw_init_local is intended to be async-signal safe, the one-time initialization logic invoked by init_local calls pthread_mutex_lock, which is not async-signal safe. It definitely appears to work in practice, but you could probably produce a deadlock by sending a signal to a thread while it is calling unw_init_local with a signal handler that also calls unw_init_local.
Since the lock is only taken during the one-time initialization process, a workaround is to force that initialization to happen outside of the signal handler first, but that fact should be documented.
- Vorherrschende Sprache
- C
- Sterne
- 1.3k
- Forks
- 353
- Ø Merge
- 3 T. 19 Std.
- Gemergte PRs (30 T.)
- 11
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus libunwind/libunwind
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 4 Tagen
-
build fails on muslOffenbug
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 55/100
Maintainer antworten meist innerhalb von 4 Tagen
-
v1.8.3 not taggedOffenbug
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 55/100
libunwind/libunwind#1076 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 4 Tagen
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
Maintainer antworten meist innerhalb von 4 Tagen
-
New release?Offenenhancement
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 12/100
libunwind/libunwind#1030 · 7 Kommentare ·
Maintainer antworten meist innerhalb von 4 Tagen
Alle Issues in libunwind/libunwind
Ähnliche Issues
-
vim.filetype.match() prefixes a URL buffer name with the cwd before passing it to filetype functionsOffen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 73/100
Maintainer antworten meist innerhalb von 1 Tag
-
stream_curl: retry_count never resets after a successful reconnect, so long sequential streams die after 5 dropsEvtl. vergeben Ein verknüpfter Pull Request ist offen oder bereits gemergt. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
mpv-player/mpv#18728 ·
Maintainer antworten meist innerhalb von 1 Tag
-
followup Prio 📌
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
cyrusimap/cyrus-imapd#6640 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 60/100
Maintainer antworten meist innerhalb von 1 Tag