Opened 10 years ago
Closed 10 years ago
#46775 closed defect (fixed)
tmux hangs on Yosemite
Reported by: | root42 | Owned by: | tessus (Helmut K. C. Tessarek) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.3 |
Keywords: | Cc: | ||
Port: | tmux |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
Since upgrading to Yosemite I am having the problem that tmux hangs after logging my user out and back in again. According to Chris Johnson this is caused by a workaround to ticket #18357.
I have disabled the workaround (i.e. the additional CPPFLAGS), and can now successfully use tmux again. So it should be considered to disable the workaround on Yosemite.
Change History (4)
comment:1 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|---|
Owner: | changed from macports-tickets@… to tessarek@… |
comment:2 Changed 10 years ago by chris_johnsen@…
I can confirm that using __DARWIN_VERS_1050
does offer a partial workaround for older OS X releases. The problem is that where that workaround simply stopped working on older releases, it causes significant problems on Yosemite. The scenario in question is this:
- In a GUI session (e.g. a Terminal or iTerm window), start a fresh tmux server.
- Observe that some special commands still work normally from inside the tmux session (i.e. the same as in a plain Terminal window):
pbpaste
andpbcopy
both work to access the pasteboardopen
can open files, folders, URLs in the normal GUI-based applications- various other things: https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard/blob/master/Usage.md#beyond-pasteboard-access
- Logout of the GUI session (while leaving the tmux server running).
- Start a new GUI session, attach to the previously started tmux session.
- Create a new tmux window.
On previous OS X releases this would work OK, but new and existing tmux children would have lost the ability to use those “special commands” above (i.e. the __DARWIN_VERS_1050
workaround is no longer effective at this point). On Yosemite, creating the new window in the last step hangs. The hang actually happens inside some internal GCD/XPC/Mach invocations that happen to be built into several basic library calls (e.g. getpwuid and localtime). The following backtrace was captured from running date
in the above-described context:
(lldb) pr at -p 36663 Process 36663 stopped warning: Executable module changed from "/bin/ls" to "/bin/date". (lldb) bt * thread #1: tid = 0x17a432, 0x00007fff8d2c74de libsystem_kernel.dylib`mach_msg_trap + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x00007fff8d2c74de libsystem_kernel.dylib`mach_msg_trap + 10 frame #1: 0x00007fff8d2c664f libsystem_kernel.dylib`mach_msg + 55 frame #2: 0x00007fff8646627e libxpc.dylib`xpc_pipe_routine + 252 frame #3: 0x00007fff8646ee02 libxpc.dylib`_xpc_interface_routine + 163 frame #4: 0x00007fff86473c45 libxpc.dylib`bootstrap_look_up3 + 248 frame #5: 0x00007fff86473b36 libxpc.dylib`bootstrap_look_up2 + 47 frame #6: 0x00007fff8955dd2e libsystem_notify.dylib`___notify_lib_init_block_invoke + 58 frame #7: 0x00007fff8e389c13 libdispatch.dylib`_dispatch_client_callout + 8 frame #8: 0x00007fff8e389b26 libdispatch.dylib`dispatch_once_f + 117 frame #9: 0x00007fff8955a3fc libsystem_notify.dylib`_notify_lib_init + 944 frame #10: 0x00007fff8955b24c libsystem_notify.dylib`notify_register_check + 159 frame #11: 0x00007fff81d1cb9c libsystem_c.dylib`notify_register_tz + 204 frame #12: 0x00007fff81d1c6c4 libsystem_c.dylib`tzsetwall_basic + 213 frame #13: 0x00007fff81d1c880 libsystem_c.dylib`_st_tzset_basic + 363 frame #14: 0x00007fff81d1dfb0 libsystem_c.dylib`localtime + 206 frame #15: 0x000000010c5ac4b3 date`___lldb_unnamed_function13$$date + 1827 frame #16: 0x00007fff8d5625c9 libdyld.dylib`start + 1
So, __DARWIN_VERS_1050
is somewhat helpful on older releases (I just re-tested this on 10.9, but I can not currently go back any further; though I remember testing on 10.6 when I first wrote reattach-to-user-namespace almost four years ago).
But __DARWIN_VERS_1050
is harmful on Yosemite in a context that could be a quite common for tmux users (i.e. leaving a tmux-based terminal session running while logging out the main GUI session).
I would suggest only using __DARWIN_VERS_1050
on pre-Yosemite releases. Yosemite seems to have its own fix for accessing the pasteboard in the above-described context, so that at least mitigates some of the problems that __DARWIN_VERS_1050
would normally help with (pre-logout; other commands like open
will fail post-logout, but this is arguably better than causing every child of tmux to eventually hang).
comment:3 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
This makes no sense. The only point of our setting __DARWIN_VERS_1050=0
is to force pre-Leopard behavior for daemon(3) when running on Yosemite, so that daemon(3) won't cause tmux to leave the aqua session (which is what causes pbpaste, etc to no longer work as you expect). This is only needed on Yosemite in order to work around a Yosemite regression. It would make absolutely no sense to just do __DARWIN_VERS_1050=0
pre-Yosemite since the only place it is needed is on Yosemite.
That being said, the regression is fixed in 10.10.2, so we could remove it.
To clarify a bit of your misunderstanding, what you are observing in step 4 and step 5 is that the user's aqua session is being destroyed on user logout, so tmux (and its children) no longer have a valid bootstrap port at that point.
The main problem is that tmux isn't properly layered. It wants to be in the user session but have access to services in the aqua session subset.
comment:4 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → fixed |
---|---|
Status: | new → closed |
So, you would like us to revert r127986? Note that r127986 was supposed to have worked around a bug, so reverting it will reintroduce that bug.