From owner-freebsd-arch@freebsd.org Wed May 30 00:16:40 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3172FFC37CA for ; Wed, 30 May 2018 00:16:40 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4A8585DDC; Wed, 30 May 2018 00:16:39 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 6FEF75A9F12; Wed, 30 May 2018 00:16:38 +0000 (UTC) Date: Wed, 30 May 2018 00:16:38 +0000 From: Brooks Davis To: Gleb Popov Cc: freebsd-arch@freebsd.org Subject: Re: Rationale for setting COMMLEN to 19 in struct kinfo_proc Message-ID: <20180530001638.GN99063@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vbzKE9fGfpHIBC6T" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 00:16:40 -0000 --vbzKE9fGfpHIBC6T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 29, 2018 at 11:42:47PM +0300, Gleb Popov wrote: > Hello. >=20 > I've been debugging a failing Qt (KDE, to be precise) test and found that > process name returned in kinfo_proc structure gets truncated to 19 symbol= s. > This causes other errors in the application. I'm wondering why is this > field so small and is there possibility to increase it? I think, having > applications with names longer than 19 characters is not that rare. >=20 > Relevant header: /usr/include/sys/user.h >=20 > Simple testcase to feature the problem: >=20 > # cat k.cpp > #include > #include > #include > #include >=20 > #include > #include > #include > #include >=20 > int main() > { > auto pid =3D getpid(); > struct kinfo_proc kp; > int mib[4] =3D { CTL_KERN, KERN_PROC, KERN_PROC_PID, (int)pid }; >=20 > size_t len =3D sizeof(kp); > u_int mib_len =3D sizeof(mib)/sizeof(u_int); >=20 > if (sysctl(mib, mib_len, &kp, &len, NULL, 0) < 0) > return -1; >=20 > puts(kp.ki_tdname); > puts(kp.ki_comm); >=20 > return 0; > } > # c++ -o abcdefghijklmnopqrstuvwxyz > # ./abcdefghijklmnopqrstuvwxyz > abcdefghijklmnop > abcdefghijklmnopqrs Changing the size of fields in kinfo_proc would be enormously disruptive. Take a look at all the source that uses KERN_PROC_PID for a subset of things that would break. Sometimes we can break these interfaces, but I think this one would require new sysctl mibs. If we did that we should come up with an interface that is identical between 32-bit and 32-bit systems and doesn't export pointers. -- Brooks --vbzKE9fGfpHIBC6T Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbDe1lAAoJEKzQXbSebgfAvp0H/2e09ofL4ZQyHkzbnnskb54V Aghoi0n6oDRBXdxgq9Tza1rXXfq57wGj/Zperb0H9GO3BJzQW9Hbx8FPPWfO42vP WJJYc+IhJ3ikLE18+XprUdVOlOiNBbW57qx5dnQ6WtsVBBFBdxgKq3fe/3ocOKNQ 0lE61pfhx01pwj5KGNtVQOKRqUF4DwTbCj2+PLCPlguXQ1rlVHv62i/4W24JpG7F EDvoHJ6DZ/N/yePBPA1b1P/VVbDoWxIpti934cqZhGpZd+jF1fDK9AfbGUNA2Adq 72pWZhirWL1nnFEkZVvNoKIYVEMaY+WPJ6nTCb5VWDQfm8lmf+qFhKcUjrGN5Y0= =s08Z -----END PGP SIGNATURE----- --vbzKE9fGfpHIBC6T--