Opened 9 years ago

Closed 9 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 9 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Owner: changed from macports-tickets@… to tessarek@…

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.

comment:2 Changed 9 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:

  1. In a GUI session (e.g. a Terminal or iTerm window), start a fresh tmux server.
  2. Observe that some special commands still work normally from inside the tmux session (i.e. the same as in a plain Terminal window):
  3. Logout of the GUI session (while leaving the tmux server running).
  4. Start a new GUI session, attach to the previously started tmux session.
  5. 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 9 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.

Last edited 9 years ago by jeremyhu (Jeremy Huddleston Sequoia) (previous) (diff)

comment:4 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.