NetBSD Problem Report #50393

From he@smistad.uninett.no  Mon Nov  2 12:28:03 2015
Return-Path: <he@smistad.uninett.no>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 66B01A5864
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  2 Nov 2015 12:28:03 +0000 (UTC)
Message-Id: <20151102122756.3421E3D0B5@smistad.uninett.no>
Date: Mon,  2 Nov 2015 13:27:56 +0100 (CET)
From: he@uninett.no
Reply-To: he@uninett.no
To: gnats-bugs@gnats.NetBSD.org
Subject: Crash in signal-induced process exit
X-Send-Pr-Version: 3.95

>Number:         50393
>Category:       kern
>Synopsis:       Crash in signal-induced process exit
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 02 12:30:00 +0000 2015
>Originator:     Havard Eidnes
>Release:        NetBSD 6.1_STABLE
>Organization:
	UNINETT AS
>Environment:
System: NetBSD hugin.uninett.no 6.1_STABLE NetBSD 6.1_STABLE (HUGIN) #2: Thu Oct  9 22:05:07 CEST 2014  he@hugin.uninett.no:/usr/obj/sys/arch/amd64/compile/HUGIN amd64
Architecture: amd64
Machine: amd64
>Description:
	One of our servers crashed with what looks like a null pointer
	de-reference somewhere deep down under a signal-induced exit
	event.  The panic + traceback logged to the console was:

uvm_fault(0xfffffe8e05ee27a0, 0x55f0a000, 2) -> e
fatal page fault in supervisor mode
trap type 6 code 2 rip ffffffff804d218e cs 8 rflags 10202 cr2  55f0a756 cpl 8 rsp fffffe8178130910
panic: trap
cpu0: Begin traceback...
printf_nolog() at netbsd:printf_nolog
startlwp() at netbsd:startlwp
alltraps() at netbsd:alltraps+0x96
cv_wakeup_all() at netbsd:cv_wakeup_all+0x4b
pipeclose() at netbsd:pipeclose+0x9e
pipe_close() at netbsd:pipe_close+0x18
closef() at netbsd:closef+0x4a
fd_free() at netbsd:fd_free+0xba
exit1() at netbsd:exit1+0xf9
sigexit() at netbsd:sigexit+0x139
postsig() at netbsd:postsig+0xfa
lwp_userret() at netbsd:lwp_userret+0x17a
syscall() at netbsd:syscall+0x161
cpu0: End traceback...

	Unfortunately, I had not turned on machdep.sparse_dump, and
	it's not set by default in netbsd-6, and dumping the 64GB
	memory looked like it would take the better part of the day,
	so the machine got power cycled when it had around 39GB left
	to dump.  Not sure if the resulting crash dump is worth
	anything.

>How-To-Repeat:
	I don't exactly know exactly how to reproduce this problem,
	sorry.  It's the first occurrance I can remember of seeing
	this over a 2-year period.
>Fix:
	No fix, sorry...

Home	PR Database Search