Kernel panic when closing iTerm2 tmux integration session

Originator:kam
Number:rdar://12368202 Date Originated:9/25/2012
Status:Open Resolved:
Product:Mac OS X Product Version:10.7.5
Classification:Crash/Hang/Data loss Reproducible:Always
 
25-Sep-2012 11:52 AM Kevin Mitchell:
Summary: When closing a tmux integration window in iTerm 2 while other windows using that integration are open, a kernel panic occurs.

Steps to Reproduce: Get iTerm2. Create a tmux integration session targeting another machine. Open a few session windows. Now rapidly close all the windows or exit the app.

More information on tmux integration: http://code.google.com/p/iterm2/wiki/TmuxIntegration

You need tmux with patches. I believe this is the branch of tmux to compile on the remote machine. https://github.com/gnachman/tmux2/tree/command_mode

Expected Results: Windows close.

Actual Results: Kernel panic.

Regression:

Notes:

See also iTerm2 bug report: http://code.google.com/p/iterm2/issues/detail?id=1765&q=kernel


The code looks like this, and I've marked where I suspect the bug is. Accessing vcount(vp) without a lock on the device, probably a race condition on multiprocessor machines. The major number in the crash dumps corresponds to /dev/ttys000 and following.

(spec_vnops.c)

	case VCHR:
		/*
		 * Hack: a tty device that is a controlling terminal
		 * has a reference from the session structure.
		 * We cannot easily tell that a character device is
		 * a controlling terminal, unless it is the closing
		 * process' controlling terminal.  In that case,
		 * if the reference count is 1 (this is the very
		 * last close)
		 */
		sessp = proc_session(p);
		if (sessp != SESSION_NULL) {

/* KAM - I think this is the bug: accessing vcount(vp) without devsw_lock(dev, S_IFCHR)
   See the code later on, and also  for VBLK. */

			if (vp == sessp->s_ttyvp && vcount(vp) == 1) {
				struct tty *tp;

				session_lock(sessp);
				if (vp == sessp->s_ttyvp) {
					tp = SESSION_TP(sessp);
					sessp->s_ttyvp = NULL;
					sessp->s_ttyvid = 0;
					sessp->s_ttyp = TTY_NULL;
					sessp->s_ttypgrpid = NO_PID;
					do_rele = 1;
				} 
				session_unlock(sessp);

				if (do_rele) {
					vnode_rele(vp);
					if (NULL != tp)
						ttyfree(tp);
				}
			}
			session_rele(sessp);
		}

		devsw_lock(dev, S_IFCHR);

		if (--vp->v_specinfo->si_opencount < 0)
			panic("negative open count (c, %u, %u)", major(dev), minor(dev));

		/*
		 * close always, or close on last reference, or close on revoke
		 */
		if ((D_TRACKCLOSE & cdevsw[major(dev)].d_type) != 0 ||
		    vcount(vp) == 0 || (flags & IO_REVOKE) != 0)
			error = cdevsw[major(dev)].d_close(dev, flags, S_IFCHR, p);

		devsw_unlock(dev, S_IFCHR);
		break;


	case VBLK:
		/*
		 * If there is more than one outstanding open, don't
		 * send the close to the device.
		 */
		devsw_lock(dev, S_IFBLK); /* KAM - note the lock here! */
		if (vcount(vp) > 1) {
			vp->v_specinfo->si_opencount--;
			devsw_unlock(dev, S_IFBLK);
			return (0);
		}
		devsw_unlock(dev, S_IFBLK);


25-Sep-2012 11:52 AM Kevin Mitchell:
'Kernel_2012-09-25-114117_Xoots.panic' was successfully uploaded

Comments

Also happens with ssh.

Still seeing this in Mavericks (seen twice in last month). Most recently, it occurred when trying to ssh to a bad ip address (no route or no response?), hitting ctrl-c in iterm2, then trying to ssh to a unresolvable domain name (irrelevant?).

Here is a partial diagnostic report. Not sure how to view this version of spec_vnops.c.

Anonymous UUID: 7A4C690D-D16A-FC07-98C0-8FE49E531ED3

Wed Mar 26 08:33:35 2014 panic(cpu 2 caller 0xffffff800100c91f): "negative open count (c, 16, 1)"@/SourceCache/xnu/xnu-2422.90.20/bsd/miscfs/specfs/spec_vnops.c:2110 Backtrace (CPU 2), Frame : Return Address 0xffffff81d2163b40 : 0xffffff8000e22fa9 0xffffff81d2163bc0 : 0xffffff800100c91f 0xffffff81d2163c00 : 0xffffff8001011d86 0xffffff81d2163c50 : 0xffffff8000ffd79e 0xffffff81d2163cc0 : 0xffffff8000fdbc51 0xffffff81d2163d10 : 0xffffff8000fdb3a0 0xffffff81d2163d50 : 0xffffff8000fdbedd 0xffffff81d2163d80 : 0xffffff8000ffdec3 0xffffff81d2163dd0 : 0xffffff80011ccb76 0xffffff81d2163e50 : 0xffffff8000e456e9 0xffffff81d2163e80 : 0xffffff8000e487b9 0xffffff81d2163eb0 : 0xffffff8000e4861e 0xffffff81d2163ee0 : 0xffffff8000e20b93 0xffffff81d2163f10 : 0xffffff8000edc463 0xffffff81d2163f30 : 0xffffff8000ef32f2

BSD process name corresponding to current thread: ssh

Mac OS version: 13C64

Kernel version: Darwin Kernel Version 13.1.0: Thu Jan 16 19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 Kernel UUID: 9FEA8EDC-B629-3ED2-A1A3-6521A1885953 Kernel slide: 0x0000000000c00000 Kernel text base: 0xffffff8000e00000 System model name: MacBookPro9,1 (Mac-4B7AC7E43945597E)

System uptime in nanoseconds: 1712659897577250 last loaded kext at 1712076568625112: com.apple.driver.AppleIntelMCEReporter 104 (addr 0xffffff7f83541000, size 49152) last unloaded kext at 1712148499878001: com.apple.driver.AppleIntelMCEReporter 104 (addr 0xffffff7f83541000, size 32768) loaded kexts: com.seagate.driver.PowSecLeafDriver_10_5 5.1.1 com.seagate.driver.PowSecDriverCore 5.1.1 org.virtualbox.kext.VBoxNetAdp 4.3.8 org.virtualbox.kext.VBoxNetFlt 4.3.8 org.virtualbox.kext.VBoxUSB 4.3.8 org.virtualbox.kext.VBoxDrv 4.3.8

By NerdMachine at March 26, 2014, 1:14 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!