NetBSD Problem Report #38107

From root@kemobile.girsa.ro  Tue Feb 26 08:12:26 2008
Return-Path: <root@kemobile.girsa.ro>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id CE1F363B853
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 26 Feb 2008 08:12:25 +0000 (UTC)
Message-Id: <20080226081220.E1802323308@kemobile.girsa.ro>
Date: Tue, 26 Feb 2008 10:12:20 +0200 (EET)
From: kefren@ngnetworks.ro
Reply-To: kefren@ngnetworks.ro
To: gnats-bugs@gnats.NetBSD.org
Subject: recent crash in -current
X-Send-Pr-Version: 3.95

>Number:         38107
>Category:       kern
>Synopsis:       crash in -current under diskload
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 26 08:15:00 +0000 2008
>Closed-Date:    Tue Nov 20 21:20:44 +0000 2018
>Last-Modified:  Tue Nov 20 21:20:44 +0000 2018
>Originator:     Mihai Chelaru
>Release:        NetBSD 4.99.54
>Organization:

>Environment:


System: NetBSD kemobile.girsa.ro 4.99.54 NetBSD 4.99.54 (Kefren) #1: Sun Feb 24 17:26:04 EET 2008 kefren@kemobile.girsa.ro:/usr/work/src/sys/arch/i386/compile/obj/Kefren i386
Architecture: i386
Machine: i386
>Description:


	Under heavy diskload (extracting firefox sources, rm -rf /usr/src) I get the following:

#0  0xc046cff2 in cpu_reboot (howto=260, bootstr=0x0) at /usr/work/src/sys/arch/i386/i386/machdep.c:952
952                     dumpsys();
(gdb) bt
#0  0xc046cff2 in cpu_reboot (howto=260, bootstr=0x0) at /usr/work/src/sys/arch/i386/i386/machdep.c:952
#1  0xc03d80fa in panic (fmt=0xc067ef24 "trap") at /usr/work/src/sys/kern/subr_prf.c:260
#2  0xc0471123 in trap (frame=0xcb708af8) at /usr/work/src/sys/arch/i386/i386/trap.c:372
#3  0xc01030c8 in calltrap ()
#4  0xc040d0ba in VFS_SYNC (mp=0xca4fb600, a=0, b=0x0) at /usr/work/src/sys/kern/vfs_subr2.c:1102
#5  0xc040c16d in vfs_shutdown () at /usr/work/src/sys/kern/vfs_subr.c:1810
#6  0xc046d0c9 in cpu_reboot (howto=256, bootstr=0x0) at /usr/work/src/sys/arch/i386/i386/machdep.c:938
#7  0xc03d80fa in panic (fmt=0xc067ef24 "trap") at /usr/work/src/sys/kern/subr_prf.c:260
#8  0xc0471123 in trap (frame=0xcb708c70) at /usr/work/src/sys/arch/i386/i386/trap.c:372
#9  0xc01030c8 in calltrap ()
#10 0xc040d0ba in VFS_SYNC (mp=0xcb708cdc, a=65554, b=0xc05e89a0) at /usr/work/src/sys/kern/vfs_subr2.c:1102
#11 0xc0417a73 in VOP_FSYNC (vp=0xcba39008, cred=0xca4e4f00, flags=8, offlo=0, offhi=0)
    at /usr/work/src/sys/kern/vnode_if.c:804
#12 0xc041eeba in sched_sync (v=0xca4fb600) at /usr/work/src/sys/miscfs/syncfs/sync_subr.c:223
#13 0xc01002cf in lwp_trampoline ()

>How-To-Repeat:

>Fix:


>Release-Note:

>Audit-Trail:
From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/38107: recent crash in -current
Date: Tue, 26 Feb 2008 12:41:31 +0000

 If it happens again, please go to the frame with the original VOP_SYNC()
 - not the one done during vfs_shutdown() - and do "print *mp" and "print
 *(mp->mnp_op)".

 Did you happen to unmount a file system just before the crash? It's likely
 something using the kmem allocator is corrupting kernel memory. I've seen
 evidence that indicates there is such a bug currently, so it may not be
 directly caused by VFS.

 Andrew

From: Andrew Doran <ad@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/38107: recent crash in -current
Date: Tue, 26 Feb 2008 13:24:08 +0000

 On Tue, Feb 26, 2008 at 08:15:01AM +0000, kefren@ngnetworks.ro wrote:

 > #11 0xc0417a73 in VOP_FSYNC (vp=0xcba39008, cred=0xca4e4f00, flags=8, offlo=0, offhi=0)
 >     at /usr/work/src/sys/kern/vnode_if.c:804

 Also, if you can print that vnode it would be useful too.

 Thanks,
 Andrew

From: Mihai Chelaru <kefren@ngnetworks.ro>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: kern/38107: recent crash in -current
Date: Tue, 26 Feb 2008 16:17:46 +0200

 #11 0xc0417a73 in VOP_FSYNC (vp=0xcba39008, cred=0xca4e4f00, flags=8, offlo=0, 
 offhi=0)
     at /usr/work/src/sys/kern/vnode_if.c:804
 804             error = (VCALL(vp, VOFFSET(vop_fsync), &a));
 (gdb) print *vp
 $1 = {v_uobj = {vmobjlock = {u = {mtxa_owner = 0}}, pgops = 0xc05e5a20, memq = 
 {tqh_first = 0x0, tqh_last = 0xcba39010},
     uo_npages = 0, uo_refs = 2}, v_cv = {cv_wmesg = 0xc065f8d4 "vnode", 
 cv_waiters = 0}, v_size = -1, v_writesize = -1,
   v_iflag = 2113536, v_vflag = 0, v_uflag = 0, v_numoutput = 0, v_writecount = 
 1, v_holdcnt = 0, v_synclist_slot = 2,
   v_mount = 0xcbb31000, v_op = 0xc10fea00, v_freelist = {tqe_next = 0x0, 
 tqe_prev = 0x0}, v_freelisthd = 0x0,
   v_mntvnodes = {tqe_next = 0x0, tqe_prev = 0xcbb31008}, v_cleanblkhd = 
 {lh_first = 0x0}, v_dirtyblkhd = {lh_first = 0x0},
   v_synclist = {tqe_next = 0x0, tqe_prev = 0xc10f7610}, v_dnclist = {lh_first 
 = 0x0}, v_nclist = {lh_first = 0x0}, v_un = {
     vu_mountedhere = 0x0, vu_socket = 0x0, vu_specnode = 0x0, vu_fifoinfo = 
 0x0, vu_ractx = 0x0}, v_type = VNON,
   v_tag = VT_VFS, v_lock = {vl_lock = {rw_owner = 0}, vl_canrecurse = 0, 
 vl_recursecnt = 0}, v_vnlock = 0xcba39094,
   v_data = 0x0, v_klist = {slh_first = 0x0}}

 -- 
 Mihai

From: Mihai Chelaru <kefren@ngnetworks.ro>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: kern/38107: recent crash in -current
Date: Tue, 26 Feb 2008 15:14:04 +0200

 On Tuesday 26 February 2008 14:45:02 Andrew Doran wrote:
 >  If it happens again, please go to the frame with the original VOP_SYNC()
 >  - not the one done during vfs_shutdown() - and do "print *mp" and "print
 >  *(mp->mnp_op)".

 (gdb) frame
 #10 0xc040d0ba in VFS_SYNC (mp=0xcb708cdc, a=65554, b=0xc05e89a0) 
 at /usr/work/src/sys/kern/vfs_subr2.c:1102
 1102            error = (*(mp->mnt_op->vfs_sync))(mp, a, b);
 (gdb) print *mp
 Cannot access memory at address 0xcb708cdc
 (gdb) print mp->mnt_op
 $4 = (struct vfsops *) 0x0

 I don't know how corrupted it is but maybe you'll need the rest of the garbage 
 also.

 (gdb) print mp->mnt_lock
 $7 = {rw_owner = 3416494088}
 (gdb) print mp->mnt_flag
 $8 = 0
 (gdb) print mp->mnt_vnodecovered
 $9 = (struct vnode *) 0x0
 (gdb) print mp->mnt_writer
 $10 = (struct lwp *) 0xc041eeba
 (gdb) print mp->mnt_stat
 Cannot access memory at address 0xcb708d24
 (gdb) print mp->mnt_fs_bshift
 $11 = 0
 (gdb) print mp->mnt_dev_bshift
 $12 = -900745728
 (gdb) print *mp->mnt_writer
 $13 = {l_runq = {tqe_next = 0xe8241c89, tqe_prev = 0xfffec83e}, l_sched_info = 
 0xffff40e9, l_cpu = 0x643d3bff,
   l_mutex = 0x75c06c92, l_ctxswtch = -308239967, l_addr = 0x4c7c06b, l_md = 
 {md_regs = 0x73800424, md_flags = 608471488,
     md_astpending = 2147268616}, l_flag = 1149878387, l_stat = -1813511132, 
 l_rtime = {sec = -335546300,
     frac = 6765965473748418689}, l_stime = {sec = -1913222717, frac = 
 9895815756216543164}, l_swtime = 149717989,
   l_holdcnt = 3945006279, l_biglocks = -390043757, l_class = -290882, 
 l_kpriority = -1010188239, l_kpribase = -1929349491,
   l_priority = 10172, l_inheritedprio = 827654144, l_pi_lenders = {slh_first = 
 0x83e589c0}, l_ncsw = 5011103564194973932,
   l_nivcsw = 16727499902489234184, l_cpticks = -29178, l_pctcpu = 3284779057, 
 l_estcpu = 2304112265, l_psid = 418153445,
   l_target_cpu = 0x8bfc7d89, l_swaplock = {u = {mtxa_owner = 1569261693}}, 
 l_lwpctl = 0xf87589f4, l_lcpage = 0xf6045f8b,
   l_affinity = {bits = {2332560455}}, l_ts = 0x12754c73, l_syncobj = 
 0x31f45d8b, l_sleepchain = {tqe_next = 0xf8758bc0,
     tqe_prev = 0x89fc7d8b}, l_wchan = 0x8dc35dec, l_wmesg = 0x1c890076 
 <Address 0x1c890076 out of bounds>,
   l_sleepq = 0x4248e824, l_sleeperr = 950140878, l_slptime = 2311089309, 
 l_timeout_ch = {_c_store = {0x4489241c,
       0x97e80424, 0x89fffffc, 0x1bb241c, 0xe8000000, 0xffce424a, 0x402404c7, 
 0xe8c0759c, 0xffce421e, 0x759c40b8}},
   l_list = {le_next = 0x244489c0, le_prev = 0x245c8908}, l_ctxlink = 
 0x24348904, l_proc = 0xfecc69e8, l_sibling = {
     le_next = 0x75c085ff, le_prev = 0x385e8b3b}, l_waiter = 953, l_waitingfor 
 = -2082961152, l_prflag = 1183432672,
   l_refcnt = 138906424, l_lid = 69487753, l_selflag = -1994115959, l_selwait = 
 {slh_first = 0xe8082444},
   l_name = 0xfffee0d2 <Address 0xfffee0d2 out of bounds>, l_sigrestore = 
 1967178742, l_sigwaitset = {__bits = {2312253732,
       2298750036, 3488097332, 3925868224}}, l_sigcv = {cv_wmesg = 0xffffff68 
 <Address 0xffffff68 out of bounds>,
     cv_waiters = 1076102343}, l_sigwaited = 0xe8c0759c, l_sigpendset = 
 0xffce41de, l_sigwaiter = {le_next = 0xffff57e9,
     le_prev = 0x384e83ff}, l_sigstk = {ss_sp = 0x89d23140, ss_size = 
 2298750036, ss_flags = -1477958604}, l_sigmask = {
     __bits = {3925868224, 4294967104, 2304112265, 3968029669}}, l_sigpend = 
 {sp_info = {cqh_first = 0x8458b04,
       cqh_last = 0xc718588b}, sp_set = {__bits = {6208, 478740480, 1099229220, 
 478805966}}}, l_sigoldmask = {__bits = {
       4218218532, 1137180671, 64, 605849856}}, l_specdataref = 
 {specdataref_container = 0xce418de8, specdataref_lock = {
       u = {mtxa_owner = 140347903}}}, l_ktrcsw = {tv = {tv_sec = -379757736, 
 tv_usec = -80334}, ts = {tv_sec = -379757736,
       tv_nsec = -80334}}, l_private = 0x8955f689, l_switchto = 0x38ec83e5, 
 l_cred = 0x89f0458d, l_emuldata = 0x758bf875,
   l_cv_signalled = 608471304, l_shlocks = 41228, l_exlocks = 40580, l_locks = 
 49269, l_blcnt = 23945, l_pflag = -58881548,
   l_dupfd = 69497993, l_syscall_time = 136594569, l_syscall_counter = 
 0x152404c7}

 >  Did you happen to unmount a file system just before the crash? It's likely
 >  something using the kmem allocator is corrupting kernel memory. I've seen
 >  evidence that indicates there is such a bug currently, so it may not be
 >  directly caused by VFS.

 Nope, no unmount since system started.

State-Changed-From-To: open->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Tue, 20 Nov 2018 21:20:44 +0000
State-Changed-Why:
Closing stale bug report. All we can go by is a backtrace for a very old version of NetBSD. This code is very heavily used and any problems on it will show up in additional bug reports if reproducible. Sorry your bug wasn't addressed at the time.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.