From owner-freebsd-stable@FreeBSD.ORG Thu Dec 23 07:48:41 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 200A016A4CE for ; Thu, 23 Dec 2004 07:48:41 +0000 (GMT) Received: from negaverse.org (207.127.234.151.lightlink.com [207.127.234.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42EB143D45 for ; Thu, 23 Dec 2004 07:48:40 +0000 (GMT) (envelope-from lucas@negaverse.org) Received: (qmail 74687 invoked by uid 98); 23 Dec 2004 07:48:37 -0000 Received: from 69.202.67.181 by zoisite.negaverse.org (envelope-from , uid 82) with qmail-scanner-1.24 (f-prot: 4.3.2/3.14.7. spamassassin: 3.0.1. Clear:RC:1(69.202.67.181):. Processed in 0.139097 secs); 23 Dec 2004 07:48:37 -0000 X-Qmail-Scanner-Mail-From: lucas@negaverse.org via zoisite.negaverse.org X-Qmail-Scanner: 1.24 (Clear:RC:1(69.202.67.181):. Processed in 0.139097 secs) Received: from syr-69-202-67-181.twcny.rr.com (HELO ?192.168.1.66?) (69.202.67.181) by 207.127.234.151.lightlink.com with AES256-SHA encrypted SMTP; 23 Dec 2004 07:48:36 -0000 Message-ID: <41CA7846.2020604@negaverse.org> Date: Thu, 23 Dec 2004 02:48:22 -0500 From: Lucas Madar User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: panic in 5.3-stable related to heavy usage and libthr X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Dec 2004 07:48:41 -0000 I updated a machine today to 5.3-STABLE and almost instantly it crashed when a heavily threaded program ran. (The machine was previously running 5.2-release). This crash is reproducible under heavy load with four threads using libthr -- I haven't tested any other variances on this scheme, and I will be testing 5.3-RELEASE tomorrow to see if it exhibits the same problems. relevant info from kgdb, with null pointer goodness. #23 0x00000000 in ?? () #24 0xc055681f in sleepq_remove_thread (sq=0x0, td=0x0) at /data/rootsystem/src/sys/kern/subr_sleepqueue.c:581 #25 0xc0556a16 in sleepq_signal (wchan=0xc2b91320, flags=0, pri=-1) at /data/rootsystem/src/sys/kern/subr_sleepqueue.c:677 #26 0xc053fa53 in wakeup_one (ident=0xc2b91320) at /data/rootsystem/src/sys/kern/kern_synch.c:266 #27 0xc0543052 in thr_wake (td=0xc2b91000, uap=0xc2b91000) at /data/rootsystem/src/sys/kern/kern_thr.c:303 #28 0xc0698c9f in syscall (frame= {tf_fs = 134742063, tf_es = 134742063, tf_ds = -1078001617, tf_edi = 134558784, tf_esi = 135229440, tf_ebp = -1079198052, tf_isp = -378659468, tf_ebx = 671863452, tf_edx = 134558792, tf_ecx = 0, tf_eax = 443, tf_trapno = 22, tf_err = 2, tf_eip = 672179195, tf_cs = 31, tf_eflags = 662, tf_esp = -1079198096, tf_ss = 47}) at /data/rootsystem/src/sys/i386/i386/trap.c:1001 #29 0xc0686c1f in Xint0x80_syscall () at /data/rootsystem/src/sys/i386/i386/exception.s:201 Is this useful to anyone? I'll keep this around if you need to poke at any structures. - lucas