NetBSD Problem Report #55665

From martin@duskware.de  Thu Sep 17 06:07:34 2020
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id C252D1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 17 Sep 2020 06:07:34 +0000 (UTC)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: reliably trigerable KASSERT with gdb -p
X-Send-Pr-Version: 3.95

>Number:         55665
>Category:       kern
>Synopsis:       reliably trigerable KASSERT with gdb -p
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kre
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 17 06:10:00 +0000 2020
>Last-Modified:  Thu Apr 02 11:40:01 +0000 2026
>Originator:     Martin Husemann
>Release:        NetBSD 9.99.72
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD unpluged.duskware.de 9.99.72 NetBSD 9.99.72 (UNPLUGED) #340: Wed Sep 16 13:35:07 CEST 2020 martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/evbarm/compile/UNPLUGED evbarm
Architecture: earmv5
Machine: evbarm
>Description:

I tried to debug makemandb and gdb "run" would not work for me, so I tried
to attach to the makemandb process with -p and immediately hit the (in-)famous
assertion:

[ 165.1514604] panic: kernel diagnostic assertion "pgrp->pg_jobc > 0" failed: f$
[ 165.1514604] cpu0: Begin traceback...
[ 165.1514604] 0xd4cafc94: netbsd:db_panic+0x14
[ 165.1514604] 0xd4cafcac: netbsd:vpanic+0x11c
[ 165.1514604] 0xd4cafcc4: netbsd:kern_assert+0x3c
[ 165.1514604] 0xd4cafd0c: netbsd:fixjobc+0x1ac
[ 165.1514604] 0xd4cafdac: netbsd:exit1+0x1c4  
[ 165.1514604] 0xd4cafdd4: netbsd:sigexit+0x1c0
[ 165.1514604] 0xd4cafe84: netbsd:postsig+0x22c
[ 165.1514604] 0xd4cafec4: netbsd:lwp_userret+0x1d4
[ 165.1514604] 0xd4cafeec: netbsd:userret+0x228
[ 165.1514604] 0xd4caffac: netbsd:syscall+0x1e4


Robert, I know you are diagnosing this issue - can we comment out the KASSERT
while you are tracking it down?

>How-To-Repeat:

This may depend on my shell setup, but for me it is as simple as:

  makemandb -Q &; gdb -p $( pgrep makemandb )

>Fix:
n/a

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->kre
Responsible-Changed-By: martin@NetBSD.org
Responsible-Changed-When: Thu, 17 Sep 2020 06:17:28 +0000
Responsible-Changed-Why:
Robert was looking at that assertion


From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/55665: reliably trigerable KASSERT with gdb -p
Date: Thu, 17 Sep 2020 13:29:40 +0700

     Date:        Thu, 17 Sep 2020 06:10:00 +0000 (UTC)
     From:        martin@NetBSD.org
     Message-ID:  <20200917061000.BF3F21A923C@mollari.NetBSD.org>

   | can we comment out the KASSERT while you are tracking it down?

 Sure, the KASSERT is of no value any more - it served its purpose already.

 kre


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/55665 CVS commit: src/sys/kern
Date: Thu, 17 Sep 2020 11:37:35 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Thu Sep 17 11:37:35 UTC 2020

 Modified Files:
 	src/sys/kern: kern_proc.c

 Log Message:
 PR kern/55665: temporarily comment out an assertion that is known to
 trigger in some conditions (where ignoring the wrap around does no harm
 for now)


 To generate a diff of this commit:
 cvs rdiff -u -r1.260 -r1.261 src/sys/kern/kern_proc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Robert Elz" <kre@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/55665 CVS commit: src/sys/kern
Date: Thu, 2 Apr 2026 11:36:24 +0000

 Module Name:	src
 Committed By:	kre
 Date:		Thu Apr  2 11:36:24 UTC 2026

 Modified Files:
 	src/sys/kern: kern_proc.c

 Log Message:
 PR kern/60159 PR kern/55665  pg_jobc assertions unsafe

 It has long been known that the way that the pg_jobc field in
 struct pgrp works (or doesn't perhaps) is understood by no-one,
 yet it does seem to function.

 Its (sole) purpose is to determine whether a process group should
 be subject to terminal generated stop signals (SIGTSTP, SIGTTIN, SIGTTOU).

 That is, if there is no parent process of any of the jobs in the
 process group, which is in a different process group than the one in
 question (or it would also be affected by the signal) which can arrange
 to send a SIGCONT to the process group to restart it, or some other
 signal to terminate it, then the kernel must not stop that process
 group, or it would (could) remained stopped, orphaned, forever (or
 until some human notices and manually kills it, using some signal or
 other).

 However, the extremely convoluted calculations required to maintain
 pg_jobc, which is constantly being updated as processes are created,
 terminate, or change process groups, is not really a rational way to
 handle this.   Much better is to simply check (when about to send the
 signal) and locate a suitable parent process which could restart the
 group if stopped.   That's simple, clean, and happens only when one
 of those terminal generated signals is to be sent.

 Eventually the kernel will be changed to work that way.

 However, there seems to be no urgency - pg_jobc as we have it
 now seems to function correctly, even though no-one really knows
 how (or no-one I am aware of) and any attempt to assert anything
 about its value "this simply has to be true" generally turns out
 to be false.   That is almost certainly what happened in this case.
 (kern/60159) and used to happen even more frequently in the older
 case (kern/55665).

 The assertion that caused 55665 was removed (commented out) in Sep 2020.
 However one was left (the one triggered in kern/60159), so let's just
 do away with that one for now too.

 The only possible problem that can be caused by pg_jobc malfunctions
 are orphaned process groups - which no-one ever seems to actually see,
 so worrying unduly about what race conditions might exist which allow
 the value to sometimes become what should be impossible doesn't seem
 to be a productive use of anyone's time.


 To generate a diff of this commit:
 cvs rdiff -u -r1.281 -r1.282 src/sys/kern/kern_proc.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

Home	PR Database Search