Hmmmm. Can you look at the contents of memory starting at 0xc13f7600 and going to 0xc13f7600 + 252 bytes? If GEOM is the offender then maybe phk can more easily recognize what could possibly be trashing a freed malloc()'d buffer 252-bytes in size. Sorry for the top-post. -Bosko On Wed, Aug 06, 2003 at 12:27:22PM +1000, Tim Robbins wrote: > While trying to reproduce the "wdrain" problems ru_at_ reported in the "MSDOSFS > woes" thread, I kept running into this panic. I've also seen a similar one > but didn't keep the vmcore for it where a LOR is detected between Giant and > filedesc, then a page fault occurs. The backtrace for that one shows that the > fault occurred in the file desc code, and traces down to an ioctl() syscall > issued by the shell (ksh). > > Kernel is trimmed down -current as of ~13:30 GMT on Aug 5 w/ obsolete drivers > (pcvt, gsc, etc.) deleted, but with no other significant changes. > > > Memory modified after free 0xc13f7600(252) > panic: Most recently used by GEOM > > panic: from debugger > Uptime: 5m33s > Dumping 64 MB > ata0: resetting devices .. > done > 16 32 48 > --- > #0 doadump () at /home/tim/p4/freebsd/sys/kern/kern_shutdown.c:240 > 240 dumping++; > (kgdb) bt > #0 doadump () at /home/tim/p4/freebsd/sys/kern/kern_shutdown.c:240 > #1 0xc01a19ac in boot (howto=260) at > /home/tim/p4/freebsd/sys/kern/kern_shutdown.c:372 > #2 0xc01a1d37 in panic () at > /home/tim/p4/freebsd/sys/kern/kern_shutdown.c:550 > #3 0xc0127042 in db_panic () at /home/tim/p4/freebsd/sys/ddb/db_command.c:450 > #4 0xc0126fa2 in db_command (last_cmdp=0xc031f780, cmd_table=0x0, > aux_cmd_tablep=0xc02fadc0, aux_cmd_tablep_end=0xc02fadc4) > at /home/tim/p4/freebsd/sys/ddb/db_command.c:346 > #5 0xc01270e5 in db_command_loop () at > /home/tim/p4/freebsd/sys/ddb/db_command.c:472 > #6 0xc012a0e5 in db_trap (type=3, code=0) at > /home/tim/p4/freebsd/sys/ddb/db_trap.c:73 > #7 0xc02b23ec in kdb_trap (type=3, code=0, regs=0xc5f69b68) at > /home/tim/p4/freebsd/sys/i386/i386/db_interface.c:172 > #8 0xc02c2eda in trap (frame= > {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi = -1070640529, > tf_ebp = -973694028, tf_isp = -973694060, tf_ebx = 0, tf_edx = 0, tf_ecx = 32, > tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070913874, tf_cs = 8, > tf_eflags = 646, tf_esp = -1070632808, tf_ss = -1070709550}) at > /home/tim/p4/freebsd/sys/i386/i386/trap.c:580 > #9 0xc02b3de8 in calltrap () at {standard input}:102 > #10 0xc01a1cc5 in panic (fmt=0xc02f526f "Most recently used by %s\n") at > /home/tim/p4/freebsd/sys/kern/kern_shutdown.c:534 > #11 0xc0292c5d in mtrash_ctor (mem=0xc13f7600, size=0, arg=0x0) at > /home/tim/p4/freebsd/sys/vm/uma_dbg.c:137 > #12 0xc0291434 in uma_zalloc_arg (zone=0xc083ab60, udata=0x0, flags=2) at > /home/tim/p4/freebsd/sys/vm/uma_core.c:1385 > #13 0xc0196463 in malloc (size=3229854560, type=0xc0305560, flags=2) at > /home/tim/p4/freebsd/sys/vm/uma.h:229 > #14 0xc0184cea in fdcopy (fdp=0xc1218200) at > /home/tim/p4/freebsd/sys/kern/kern_descrip.c:1309 > #15 0xc018de0e in fork1 (td=0xc0a0d390, flags=20, pages=0, procp=0xc5f69cd8) > at /home/tim/p4/freebsd/sys/kern/kern_fork.c:424 > #16 0xc018d61b in fork (td=0xc0a0d390, uap=0xc5f69d10) at > /home/tim/p4/freebsd/sys/kern/kern_fork.c:102 > #17 0xc02c37c3 in syscall (frame= > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 135299072, > tf_ebp = -1077937224, tf_isp = -973693580, tf_ebx = 0, tf_edx = 135295016, > tf_ecx = -1, tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 134725423, tf_cs > = 31, tf_eflags = 582, tf_esp = -1077937268, tf_ss = 47}) at > /home/tim/p4/freebsd/sys/i386/i386/trap.c:1008 > #18 0xc02b3e3d in Xint0x80_syscall () at {standard input}:144 > ---Can't read userspace from dump, or kernel process--- -- Bosko Milekic * bmilekic_at_technokratis.com * bmilekic_at_FreeBSD.org TECHNOkRATIS Consulting Services * http://www.technokratis.com/Received on Wed Aug 06 2003 - 04:49:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:17 UTC