From nobody@FreeBSD.org  Fri Jun 13 07:53:37 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 04A4A1065670
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 13 Jun 2008 07:53:37 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id DF1958FC19
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 13 Jun 2008 07:53:36 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m5D7rZQO026879
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 13 Jun 2008 07:53:35 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m5D7rZr7026859;
	Fri, 13 Jun 2008 07:53:35 GMT
	(envelope-from nobody)
Message-Id: <200806130753.m5D7rZr7026859@www.freebsd.org>
Date: Fri, 13 Jun 2008 07:53:35 GMT
From: Jian Qiu <swordqiu@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: kernel panic in kern_lockf.c line 294
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         124544
>Category:       kern
>Synopsis:       [panic] kernel panic in kern_lockf.c line 294
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    gavin
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jun 13 08:00:09 UTC 2008
>Closed-Date:    Mon Feb 23 14:59:30 UTC 2009
>Last-Modified:  Mon Feb 23 14:59:30 UTC 2009
>Originator:     Jian Qiu
>Release:        7.0-RELEASE
>Organization:
Huawei Corp.
>Environment:
FreeBSD routerOS12 7.0-RELEASE FreeBSD 7.0-RELEASE #5: Fri Jun 13 14:53:00 CST 2008     qj@routerOS12:/usr/obj/usr/src/sys/KERN_ULE  i386

>Description:
I wrote a program to test the multi-process multi-threading performance of
FreeBSD and libthr. In the program, I used two file locks to synchronize
the processes and a mmap shared memory to do IPC. However, the program can
cause kernel panic randomly. I used kgdb to check the resuling core dump.
It showed kernel was trapped in kern_lockf.c line 294, where it apparently
refers to a NULL pointer. Here is the code around line 294:

292:     waitblock = (struct lockf *)td->td_wchan;
293:     /* Get the owner of the blocking lock */
294:     waitblock = waitblock->lf_next;
295:     if ((waitblock->lf_flags & F_POSIX) == 0)
296:          break;
297:     nproc = (struct proc *)waitblock->lf_id;

>How-To-Repeat:
Run my program repeatedly. Sometimes, it will cause kernel panic.
>Fix:


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: gavin 
State-Changed-When: Fri Jun 13 14:12:14 UTC 2008 
State-Changed-Why:  
To submitter: please could you also provide the backtrace from kgdb? 
Also, is there any chance you can share the program that causes this 
panic? 


Responsible-Changed-From-To: freebsd-i386->gavin 
Responsible-Changed-By: gavin 
Responsible-Changed-When: Fri Jun 13 14:12:14 UTC 2008 
Responsible-Changed-Why:  
Track 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124544 
State-Changed-From-To: feedback->feedback  
State-Changed-By: gavin 
State-Changed-When: Thu Aug 21 16:13:12 UTC 2008 
State-Changed-Why:  
To submitter: Can you please update to 7-STABLE and see if this problem 
still exists?  The code in question was replaced shortly after 7.0-RELEASE 
and as a result may well already be fixed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124544 

From: "Paul A. Procacci" <pprocacci@datapipe.com>
To: bug-followup@FreeBSD.org, swordqiu@gmail.com
Cc:  
Subject: Re: kern/124544: [panic] kernel panic in kern_lockf.c line 294
Date: Sat, 11 Oct 2008 02:44:59 -0500

 I have run into the same problem as the submitter.  I have yet to 
 upgrade to -STABLE, but will try that now and report on my findings.
 
 web01# kgdb kernel.debug /var/crash/vmcore.3
 [GDB will not be able to debug user-mode threads: 
 /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain 
 conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "amd64-marcel-freebsd".
 
 Unread portion of the kernel message buffer:
 kernel trap 12 with interrupts disabled
 
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 0; apic id = 00
 fault virtual address   = 0x0
 fault code              = supervisor read data, page not present
 instruction pointer     = 0x8:0xffffffff80279c3f
 stack pointer           = 0x10:0xffffffffb44919c0
 frame pointer           = 0x10:0xffffff000be7b8d0
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags        = resume, IOPL = 0
 current process         = 5093 (php-cgi)
 trap number             = 12
 panic: page fault
 cpuid = 0
 Uptime: 49m50s
 Physical memory: 8183 MB
 Dumping 508 MB: 493 477 461 445 429 413 397 381 365 349 333 317 301 285 
 269 253 237 221 205 189 173 157 141 125 109 93 77 61 45 29 13
 
 #0  doadump () at pcpu.h:194
 194             __asm __volatile("movq %%gs:0,%0" : "=r" (td));
 
 (kgdb) list *0xffffffff80279c3f
 0xffffffff80279c3f is in lf_advlock (/usr/src/sys/kern/kern_lockf.c:295).
 290                                         (td->td_wmesg == lockstr) &&
 291                                         (i++ < maxlockdepth)) {
 292                                             waitblock = (struct 
 lockf *)td->td_wchan;
 293                                             /* Get the owner of the 
 blocking lock */
 294                                             waitblock = 
 waitblock->lf_next;
 295                                             if ((waitblock->lf_flags 
 & F_POSIX) == 0)
 296                                                     break;
 297                                             nproc = (struct proc 
 *)waitblock->lf_id;
 298                                             if (nproc == (struct 
 proc *)lock->lf_id) {
 299                                                     PROC_SUNLOCK(wproc);
 (kgdb) bt
 #0  doadump () at pcpu.h:194
 #1  0x0000000000000004 in ?? ()
 #2  0xffffffff80288319 in boot (howto=260) at 
 /usr/src/sys/kern/kern_shutdown.c:409
 #3  0xffffffff8028871d in panic (fmt=0x104 <Address 0x104 out of 
 bounds>) at /usr/src/sys/kern/kern_shutdown.c:563
 #4  0xffffffff803b95b4 in trap_fatal (frame=0xffffff0003cd3000, 
 eva=18446742974256829544) at /usr/src/sys/amd64/amd64/trap.c:724
 #5  0xffffffff803ba1ff in trap (frame=0xffffffffb4491910) at 
 /usr/src/sys/amd64/amd64/trap.c:251
 #6  0xffffffff8039ff4e in calltrap () at 
 /usr/src/sys/amd64/amd64/exception.S:169
 #7  0xffffffff80279c3f in lf_advlock (ap=Variable "ap" is not available.
 ) at /usr/src/sys/kern/kern_lockf.c:294
 #8  0xffffffff8025fbdb in kern_fcntl (td=0xffffff0003cd3000, fd=Variable 
 "fd" is not available.
 ) at vnode_if.h:1036
 #9  0xffffffff8025ff9f in fcntl (td=0xffffff0003cd3000, 
 uap=0xffffffffb4491be0) at /usr/src/sys/kern/kern_descrip.c:336
 #10 0xffffffff803b9b9e in syscall (frame=0xffffffffb4491c70) at 
 /usr/src/sys/amd64/amd64/trap.c:852
 #11 0xffffffff803a015b in Xfast_syscall () at 
 /usr/src/sys/amd64/amd64/exception.S:290
 #12 0x000000080108607c in ?? ()
 Previous frame inner to this frame (corrupt stack?)

From: "Paul A. Procacci" <pprocacci@datapipe.com>
To: bug-followup@FreeBSD.org, swordqiu@gmail.com
Cc:  
Subject: Re: kern/124544: [panic] kernel panic in kern_lockf.c line 294
Date: Sat, 11 Oct 2008 14:40:32 -0500

 For what it's worth, since upgrading to FBSD-STABLE last night, I have 
 not run into the same problem.  This of coarse being after several hours 
 of heavy testing.
State-Changed-From-To: feedback->closed 
State-Changed-By: gavin 
State-Changed-When: Mon Feb 23 14:56:50 UTC 2009 
State-Changed-Why:  
Feedback timeout (~9 months).  I suspect this is resolved with 
the new lock manager code.  Other similar panics have been 
confirmed as fixed with the new code. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=124544 
>Unformatted:
