crash in tty code in 6.1.. fixed since?
Kostik Belousov
kostikbel at gmail.com
Fri Jul 13 08:27:23 UTC 2007
On Fri, Jul 13, 2007 at 09:35:04AM +0200, Attilio Rao wrote:
> Julian Elischer wrote:
> >Does this crash look familiar to anyone?
> >It's in 6.1 unfortunatly..
> >
> >#6 0xc069ca6a in calltrap () at ../../../i386/i386/exception.s:139
> >#7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704)
> > at ../../../kern/tty.c:1659
> >#8 0xc058b83e in ptcclose (dev=0x0, flags=7, fmt=8192, td=0xc6966d80)
> > at linedisc.h:136
> >#9 0xc052bf77 in giant_close (dev=0xc7547c00, fflag=7, devtype=8192,
> >td=0xc6966d80) at ../../../kern/kern_conf.c:266
> >#10 0xc051685f in devfs_close (ap=0xe706baa4)
> > at ../../../fs/devfs/devfs_vnops.c:287
> >#11 0xc06c2a10 in VOP_CLOSE_APV (vop=0x0, a=0xc076af48) at vnode_if.c:426
> >#12 0xc05bf3ce in vn_close (vp=0xc764e550, flags=7, file_cred=0x0,
> >td=0xc6966d80) at vnode_if.h:227
> >#13 0xc05c0212 in vn_closefile (fp=0xc7532510, td=0xc6966d80)
> > at ../../../kern/vfs_vnops.c:852
> >#14 0xc0516887 in devfs_close_f (fp=0xc7532510, td=0xc6966d80)
> > at ../../../fs/devfs/devfs_vnops.c:297
> >#15 0xc05361e8 in fdrop_locked (fp=0xc7532510, td=0xc6966d80) at file.h:289
> >#16 0xc0536135 in fdrop (fp=0xc7532510, td=0xc6966d80)
> > at ../../../kern/kern_descrip.c:2122
> >#17 0xc05346d3 in closef (fp=0xc7532510, td=0xc6966d80)
> > at ../../../kern/kern_descrip.c:1942
> >#18 0xc0533487 in fdfree (td=0xc6966d80) at
> >../../../kern/kern_descrip.c:1627
> >#19 0xc053cc88 in exit1 (td=0xc6966d80, rv=15) at
> >../../../kern/kern_exit.c:263
> >#20 0xc055b58b in sigexit (td=0xc6966d80, sig=15)
> > at ../../../kern/kern_sig.c:2451
> >#21 0xc055b296 in postsig (sig=15) at ../../../kern/kern_sig.c:2326
> >#22 0xc0577fbe in ast (framep=0xe706bd38) at ../../../kern/subr_trap.c:266
> >#23 0xc069d3ad in doreti_ast () at ../../../i386/i386/exception.s:293
> >
> >(kgdb) up
> >#7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704)
> > at ../../../kern/tty.c:1659
> >1659 if (tp->t_session->s_leader) {
> >Current language: auto; currently c
> >(kgdb) list
> >1654 !ISSET(tp->t_cflag, CLOCAL)) {
> >1655 SET(tp->t_state, TS_ZOMBIE);
> >1656 CLR(tp->t_state, TS_CONNECTED);
> >1657 if (tp->t_session) {
> >1658 sx_slock(&proctree_lock);
> >1659 if (tp->t_session->s_leader) {
> >1660 struct proc *p;
> >1661
> >1662 p =
> >tp->t_session->s_leader;
> >1663 PROC_LOCK(p);
> >
> >(kgdb) set print pretty
> >(kgdb) p *tp
> >$3 = {
> > t_rawq = {
> > c_cc = 0,
> >[...]
> >
> > t_outcc = 119661, t_line = 0, t_dev = 0xc763fe00, t_mdev = 0x0,
> > t_devunit = 0, t_state = 0, t_flags = 0, t_timeout = 300000, t_pgrp
> >= 0x0, t_session = 0x0, t_sigio = 0x0, t_rsel = {
> > si_thrlist = {
> > tqe_next = 0x0, tqe_prev = 0x0
> > }, si_thread = 0x0, si_note = {
> > [...]
> >
> >
> >tp_session is NULL but it shouldn't have been able to have run that line
> >(line 1659) if it had tested NULL 2 lines before..
> >this suggests a locking problem..
>
> I think it has been fixed some months ago IIRC.
> The problem here, should be that if sx_slock() let thread sleep, Giant
> is released before to sleep and tp->t_session can be accessed in racy way.
> Another nice side-effect about having tty Giant :)
Yes, it seems that rev. 1.267 fixed it and was MFCed as rev. 1.228.2.6.
There was a lot of commits around this one, it may be safer to update to
RELENG_6.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20070713/af4dd7b4/attachment.pgp
More information about the freebsd-current
mailing list