Fix spawn_pane() with newer libevent that uses signalfd#3621
Fix spawn_pane() with newer libevent that uses signalfd#3621azat wants to merge 1 commit intotmux:masterfrom
Conversation
THere is closefrom() and after it calls proc_clear_signals() which in
turn tries to close the created signalfd and fails:
Assertion ret == 0 failed in sigfd_free_sigevent
Fix this by reorder the calls.
|
This looks OK, I will apply it tomorrow, thanks. It is not a great idea to assert if |
|
I've applied this to OpenBSD now, it will be in GitHub later, thanks! I did name you in the commit but I forget to mention the issue number. |
I thought about this, but decided to stick with assert for now, since this is for debug builds only, that should be used only by developers (who possibly could dig and fix such issues)
Thanks. Just out of curiosity why not simply merge/cherry-pick patches and instead re-apply them without original subject/author/description? P.S. maybe you should put some name here? Line 6 in e4c4ceb |
|
OK, fair enough. There are three reasons not to merge using Git:
COPYING is an example of the copyright header which appears at the top of each file, it doesn't need a name. |
signalfd may behave differently to sigaction/signal, so to avoid breaking libevent users (like [1], [2]) disable it by default. [1]: tmux/tmux#3621 [1]: tmux/tmux#3626 Also signalfd is not that perfect: - you need to SIG_BLOCK the signal before - blocked signals are not reset on exec - blocked signals are allowed to coalesce - so in case of multiple signals sent you may get the signal only once (ok for most of the signals, but may be a problem for SIGCHLD, though you may call waitpid() in a loop or use pidfd) - and also one implementation problem - sigprocmask is unspecified in a multithreaded process Refs: - https://lwn.net/Articles/415684/ - https://ldpreload.com/blog/signalfd-is-useless Refs: libevent#1460 Refs: libevent#1342 (cc @dmantipov)
signalfd may behave differently to sigaction/signal, so to avoid breaking libevent users (like [1], [2]) disable it by default. [1]: tmux/tmux#3621 [2]: tmux/tmux#3626 Also signalfd is not that perfect: - you need to SIG_BLOCK the signal before - blocked signals are not reset on exec - blocked signals are allowed to coalesce - so in case of multiple signals sent you may get the signal only once (ok for most of the signals, but may be a problem for SIGCHLD, though you may call waitpid() in a loop or use pidfd) - and also one implementation problem - sigprocmask is unspecified in a multithreaded process Refs: - https://lwn.net/Articles/415684/ - https://ldpreload.com/blog/signalfd-is-useless Refs: libevent#1460 Refs: libevent#1342 (cc @dmantipov)
signalfd may behave differently to sigaction/signal, so to avoid breaking libevent users (like [1], [2]) disable it by default. [1]: tmux/tmux#3621 [2]: tmux/tmux#3626 Also signalfd is not that perfect: - you need to SIG_BLOCK the signal before - blocked signals are not reset on exec - blocked signals are allowed to coalesce - so in case of multiple signals sent you may get the signal only once (ok for most of the signals, but may be a problem for SIGCHLD, though you may call waitpid() in a loop or use pidfd) - and also one implementation problem - sigprocmask is unspecified in a multithreaded process Refs: - https://lwn.net/Articles/415684/ - https://ldpreload.com/blog/signalfd-is-useless Refs: libevent#1460 Refs: libevent#1342 (cc @dmantipov)
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
There is closefrom() and after it calls proc_clear_signals() which in turn tries to close the created signalfd and fails:
Fix this by reorder the calls.
Fixes: #3572
Fixes: libevent/libevent#1460