Date: Thu, 28 Feb 2008 23:36:11 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: freebsd-usb@freebsd.org Subject: ucom: orphaned ttyUX ? Message-ID: <47C7294B.6020306@icyb.net.ua>
next in thread | raw e-mail | index | archive | help
I recently had a bad experience with ucom. I didn't try to reproduce it in a controlled way, so that I could fully document it. So, here's my recollection and impression/understanding of it with couple of facts on top. The bad experience: system crash with the following info: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc4611c2b stack pointer = 0x28:0xd1d3395c frame pointer = 0x28:0xd1d33974 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 8979 (pppd) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c06b76ef,d1d337fc,c04f577a,c06b4e67,c0d9f6e0,...) at 0xc0437e56 = db_trace_self_wrapper+0x26 kdb_backtrace(c06b4e67,c0d9f6e0,c06a7d40,d1d33808,d1d33808,...) at 0xc051ad69 = kdb_backtrace+0x29 panic(c06a7d40,c06cf0ab,c4219cd4,1,1,...) at 0xc04f577a = panic+0xaa trap_fatal(c4219b40,0,c06ceeff,31b,4,...) at 0xc067e5d3 = trap_fatal+0x353 trap_pfault(c06bc33a,d1d338c4,c04e9fc9,8,c,...) at 0xc067e7bb = trap_pfault+0x1db trap(d1d3391c) at 0xc067f182 = trap+0x3c2 calltrap() at 0xc066e2db = calltrap+0x6 --- trap 0xc, eip = 0xc4611c2b, esp = 0xd1d3395c, ebp = 0xd1d33974 --- ucommodem(c28f6400,3,0,c06b41c5,0,...) at 0xc4611c2b = ucommodem+0xab ttyopen(c345ed00,7,2000,c3468a50,c06ee960,...) at 0xc0535b10 = ttyopen+0x180 giant_open(c345ed00,7,2000,c3468a50,7,...) at 0xc04ca70f = giant_open+0x4f devfs_open(d1d33a70,c06d1f98,1e2,c06d267e,c3a1caa0,...) at 0xc04968c8 = devfs_open+0x1d8 VOP_OPEN_APV(c06dfee0,d1d33a70,8eb,c0558155,c3a1caa0,...) at 0xc0696062 = VOP_OPEN_APV+0x42 vn_open_cred(d1d33b64,d1d33c5c,0,c33c8800,c3823900,...) at 0xc0570b2d = vn_open_cred+0x45d vn_open(d1d33b64,d1d33c5c,0,c3823900,8,...) at 0xc0570c33 = vn_open+0x33 kern_open(c3468a50,8063280,0,7,0,...) at 0xc056f873 = kern_open+0xf3 open(c3468a50,d1d33cfc,3fe,c06cef20,c3468a50,...) at 0xc056fd70 = open+0x30 syscall(d1d33d38) at 0xc067eb03 = syscall+0x323 Xint0x80_syscall() at 0xc066e340 = Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x283123fb, esp = 0xbfbfe71c, ebp = 0xbfbfe7f8 --- Apparently, this is a "null pointer dereferencing" crash. (tried to dereference a field of structure pointed to with NULL). What happened before: connected a device recognized by ucom, /dev/ttyU0 appeared disconnected the device, ucom noticed that, but ttyU0 did not disappear re-connected the device (I believe that this time ttyU1 was created for it, but I haven't checked) by mistake used ttyU0 again got the crash I believe that this is another example of a bad use of our device cloning, but I can be very wrong here. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47C7294B.6020306>