Re: Panic in destroy_dev_sched_cb() for tty
On Tue, Jul 06, 2010 at 12:54:36AM +0200, Ed Schouten wrote: > * Jeremie Le Hen wrote: > > I've got a panic obviously from the tty layer but I couldn't get the > > panic string as no remote system was connected using serial console, and > > I don't know how to print it from DDB. > > Hmmm... This is a tricky one, but I think I do understand what's going > on here. If you close and revoke a TTY at the very exact moment, it may > call destroy_dev_sched_cb() twice, where the second time it gets called > on a null pointer. > > === > --- sys/kern/tty.c(revision 209570) > +++ sys/kern/tty.c(working copy) > @@ -1040,7 +1040,8 @@ > tp->t_dev = NULL; > tty_unlock(tp); > > - destroy_dev_sched_cb(dev, tty_dealloc, tp); > + if (dev != NULL) > + destroy_dev_sched_cb(dev, tty_dealloc, tp); > } > > void > > I guess it's very hard to reproduce, right? If so, I'll just commit it > to SVN. Thanks for reporting! Sure it is. I use screen heavily and this is the first time I get it. Please go forward, I will update my kernel after it has been MFC and I won't miss informing you if it occurs again. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic in destroy_dev_sched_cb() for tty
* Jeremie Le Hen wrote: > I've got a panic obviously from the tty layer but I couldn't get the > panic string as no remote system was connected using serial console, and > I don't know how to print it from DDB. Hmmm... This is a tricky one, but I think I do understand what's going on here. If you close and revoke a TTY at the very exact moment, it may call destroy_dev_sched_cb() twice, where the second time it gets called on a null pointer. === --- sys/kern/tty.c (revision 209570) +++ sys/kern/tty.c (working copy) @@ -1040,7 +1040,8 @@ tp->t_dev = NULL; tty_unlock(tp); - destroy_dev_sched_cb(dev, tty_dealloc, tp); + if (dev != NULL) + destroy_dev_sched_cb(dev, tty_dealloc, tp); } void I guess it's very hard to reproduce, right? If so, I'll just commit it to SVN. Thanks for reporting! -- Ed Schouten WWW: http://80386.nl/ pgpVPlQxKBSgQ.pgp Description: PGP signature
Panic in destroy_dev_sched_cb() for tty
Hi Ed, I've got a panic obviously from the tty layer but I couldn't get the panic string as no remote system was connected using serial console, and I don't know how to print it from DDB. However here is the relevant stuff I could get: db> show pcpu cpuid= 0 dynamic pcpu= 0x5a0600 curthread= 0x87cae240: pid 7701 "screen" curpcb = 0xcb1ebd90 fpcurthread = none idlethread = 0x85544900: pid 11 "idle: cpu0" APIC ID = 0 currentldt = 0x50 db> trace Tracing pid 7701 tid 100302 td 0x87cae240 destroy_dev_sched_cb(0,807137fb,9eff1200,9eff1254) at destroy_dev_sched_cb+0x10 tty_rel_free(9eff1290,0,1,0) at tty_rel_free+0xc7 ttydev_leave(9eff1290,0,0,0,0,...) at ttydev_leave+0x136 ttydev_close(9c756d00,7,2000,87cae240,cb1ebb14,...) at ttydev_close+0xf4 devfs_close(cb1ebb2c,cb1ebb50,80760b10,80a48120,cb1ebb2c,...) at devfs_close+0x3ae VOP_CLOSE_APV(80a48120,cb1ebb2c,809d7133,128,80a84000,...) at VOP_CLOSE_APV+0x44 vn_close(87cee648,7,8a965780,87cae240,80a84300,...) at vn_close+0xd1 vn_closefile(8788f658,87cae240,8788f658,0,cb1ebbe0,...) at vn_closefile+0xfe devfs_close_f(8788f658,87cae240,cb1ebc18,0,1,...) at devfs_close_f+0x27 _fdrop(8788f658,87cae240,8a965780,87cae240,865b7310,...) at _fdrop+0x43 closef(8788f658,87cae240,900fed48,2,876511d0,...) at closef+0x31b kern_close(87cae240,4,cb1ebd2c,8096147c,87cae240,...) at kern_close+0x16d close(87cae240,cb1ebcf8,4,c,c,...) at close+0x1a syscall(cb1ebd38) at syscall+0x320 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x2821b63f, esp = 0x7fbfe1bc, ebp = 0x7fbfe1c8 --- The system is running 8.0-STABLE from around 2009/12/06. Thanks. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"