Re: kern/51600 (Tracer must detect zombie before child's parent)

[Kamil Rytarowski <n54%gmx.com@localhost>]

The following reply was made to PR kern/51600; it has been noted by GNATS.

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/51600 (Tracer must detect zombie before child's parent)
Date: Sat, 19 Nov 2016 16:19:17 +0100

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 --UKuQdlGCp0EWXclLu4biSSBK1hWaJHrmG
 Content-Type: multipart/mixed; boundary="OBpKn1b1a69FrtqTVTll2ERoVxOpUii3N"
 From: Kamil Rytarowski <n54%gmx.com@localhost>
 To: gnats-bugs%NetBSD.org@localhost
 Message-ID: <db6c5431-d857-efc9-c444-37fccc3ece7d%gmx.com@localhost>
 Subject: Re: kern/51600 (Tracer must detect zombie before child's parent)
 References: <pr-kern-51600%gnats.netbsd.org@localhost>
  <20161105012720.757A37A2B2%mollari.NetBSD.org@localhost>
  <20161119060001.AD84B7A30B%mollari.NetBSD.org@localhost>
 In-Reply-To: <20161119060001.AD84B7A30B%mollari.NetBSD.org@localhost>
 
 --OBpKn1b1a69FrtqTVTll2ERoVxOpUii3N
 Content-Type: text/plain; charset=windows-1252
 Content-Transfer-Encoding: quoted-printable
 
 
 
 On 19.11.2016 07:00, Robert Elz wrote:
 > The following reply was made to PR kern/51600; it has been noted by GNA=
 TS.
 >=20
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:=20
 > Subject: Re: kern/51600 (Tracer must detect zombie before child's paren=
 t)
 > Date: Sat, 19 Nov 2016 12:58:28 +0700
 >=20
 >      Date:        Sat, 19 Nov 2016 05:05:01 +0000 (UTC)
 >      From:        Kamil Rytarowski <n54%gmx.com@localhost>
 >      Message-ID:  <20161119050501.3EA5F7A30C%mollari.NetBSD.org@localhost>
 > =20
 >    |  I will prepare a list of patches to be back-ported during weekend=
 =2E
 > =20
 >  The one that matters is kern_exit.c 1.261 -> 1.262 (Christos, 2016-11-=
 04).
 > =20
 >  (It would not hurt to also fix the preceding comment, which currently =
 says
 >  that what is now being done (to fix the panic) is not necessary...)
 > =20
 
 Right.
 
 >  All the rest of the bugs you've been finding are either in new code in=
 
 >  current (most of them), or so esoteric that they're probably not reall=
 y
 >  worth pulling up.
 > =20
 
 I'm still evaluating whether it's worth to support LLDB in -7 or -6..
 perhaps little point, while technically possible there would be rather
 needed a vendor to request/fund it. And there are more parts than
 wait(2) and ptrace(2) to make it clear (real-time signals, libpanel, new
 libstdc++ is helpful...).
 
 For now that single mentioned commit shall be enough.
 
 >  kre
 > =20
 >=20
 
 
 
 --OBpKn1b1a69FrtqTVTll2ERoVxOpUii3N--
 
 --UKuQdlGCp0EWXclLu4biSSBK1hWaJHrmG
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAEBCAAGBQJYMG2DAAoJEEuzCOmwLnZssV8P+wTfNIs1SfT8pRMwH7iPX1UQ
 bv1IcS77u8tPmh+f89oe2Dgw5gpqwM+Y3oSPRLF6e9q7dsUdEWNkhmRzdTfHnTEY
 ItJ4ddT+iy/Kyc8ySRZz4QLBoYPwq9bx9FLVDAyrgq+1SbhXMn7JbM/7kBCOwqDu
 34cJJBfERewgY54xre7n60qEpFinepAEwv/d0UCFJhT+06dSBmCl7I9XmKnwgRL9
 5B4MKoLQ8aVSMzppItLnabcCyBMzazLkYuHKTtdV/XohF316xQkXjsRDuNHHXf8l
 Zk6UXX2nVz+ENYmdJ+0UKBMCqNax1COo4b06voSAHWZOZ59h7I2vlPU73vUSOcAY
 SbvmyFLgxa6uFxXzE0lK8oH8mjR7+T50UYaSyXny2kTjIDhfea68DbzrSdNMhJuF
 ip9qrtfnnf6zWgm8T4CHolXxsLdCNS94vZot3KL4U4QiKnKWcYcQTEYttQug9LdY
 Fjm9NgCG0qW/0yfbGEbJcHRdb94ixh30cQs5mHNcBXcC7rJvfagWn4L0OoxeVv63
 bEToPu2rH4Gy9Lb6p1vUfpZR+cuifFucURxpd79pJQ9fzNCm3WfjAeoQVBSN1OQM
 gGDCgPjUgjygrsRpi8IBv+4Obe5I7xn60oZImVZEew1jsXP8K0xAFsSUeCUhZ1Qv
 z0rKpj50x0t2rQ3dpPe6
 =LRXD
 -----END PGP SIGNATURE-----
 
 --UKuQdlGCp0EWXclLu4biSSBK1hWaJHrmG--