From owner-freebsd-arch@freebsd.org Fri Jun 1 11:45:12 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 23E3BF760F5 for ; Fri, 1 Jun 2018 11:45:12 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C132C76EBF; Fri, 1 Jun 2018 11:45:11 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-pf0-f175.google.com with SMTP id a14-v6so12411060pfi.1; Fri, 01 Jun 2018 04:45:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OzQz9wY5up/XXu2ewtgKoiBxVVlZizfdY0rSPVmQq9Y=; b=YKsZjXVy8ON3ctx02qk0cFj32euH9Dk/BC74SHJkoWwPpCsQL+2h83qhpWxYnGyukb mUL1AlZwXf70tGfiacllrjf/oznB4GjYvb73d4rmzjbyFOyAW21NtqNPB4OHso54pFay 3WqiBxbs9qc+SnOUL+wFaepIgKEp19JeO7p5COP32R8AzUlUI9GPDFf18rC1VUgkyF7y e7APTUYg8SIJUxYuQrZaGPzpWN006toqBfF41srcOyC7vNWDBrd3wMZcrnggp/9MN6+S 8A8/cTtzTd+aRFj9UtUdbKUVRp+N2ZvQsLOkC31KMbdedEmVzwmjM2QaSwGztrqfe8XA SsNA== X-Gm-Message-State: ALKqPwfUmONpeT1jOCmv0wYxz7RBc61MtRzdF3KgOaSSG3JFHbHk1aTZ FMlVFVLZE+fklnirJu8STLdTsfeU X-Google-Smtp-Source: ADUXVKKS2FXM71dRZV4GpaXXIQFxe6ag+pZ+LyE84D9a6pm494MzgfUOicTpszWtjW7SR4nLqUbw5A== X-Received: by 2002:a63:7f51:: with SMTP id p17-v6mr8572092pgn.36.1527853505092; Fri, 01 Jun 2018 04:45:05 -0700 (PDT) Received: from mail-pg0-f44.google.com (mail-pg0-f44.google.com. [74.125.83.44]) by smtp.gmail.com with ESMTPSA id k80-v6sm38505756pfa.168.2018.06.01.04.45.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jun 2018 04:45:05 -0700 (PDT) Received: by mail-pg0-f44.google.com with SMTP id p8-v6so11163744pgq.10; Fri, 01 Jun 2018 04:45:04 -0700 (PDT) X-Received: by 2002:a63:4003:: with SMTP id n3-v6mr8609305pga.184.1527853504874; Fri, 01 Jun 2018 04:45:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:c502:0:0:0:0 with HTTP; Fri, 1 Jun 2018 04:44:34 -0700 (PDT) In-Reply-To: <6cdb7530-b689-7666-7ce4-9b91acfc6255@FreeBSD.org> References: <20180530001638.GN99063@spindle.one-eyed-alien.net> <6cdb7530-b689-7666-7ce4-9b91acfc6255@FreeBSD.org> From: Gleb Popov Date: Fri, 1 Jun 2018 14:44:34 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Rationale for setting COMMLEN to 19 in struct kinfo_proc To: John Baldwin Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 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: Fri, 01 Jun 2018 11:45:12 -0000 On Wed, May 30, 2018 at 5:10 AM, John Baldwin wrote: > > -- > John Baldwin > On 5/29/18 8:16 PM, Brooks Davis wrote: > > On Tue, May 29, 2018 at 11:42:47PM +0300, Gleb Popov wrote: > >> Hello. > >> > >> 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 > symbols. > >> 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. > >> > >> Relevant header: /usr/include/sys/user.h > >> > >> Simple testcase to feature the problem: > >> > >> # cat k.cpp > >> #include > >> #include > >> #include > >> #include > >> > >> #include > >> #include > >> #include > >> #include > >> > >> int main() > >> { > >> auto pid = getpid(); > >> struct kinfo_proc kp; > >> int mib[4] = { CTL_KERN, KERN_PROC, KERN_PROC_PID, (int)pid }; > >> > >> size_t len = sizeof(kp); > >> u_int mib_len = sizeof(mib)/sizeof(u_int); > >> > >> if (sysctl(mib, mib_len, &kp, &len, NULL, 0) < 0) > >> return -1; > >> > >> puts(kp.ki_tdname); > >> puts(kp.ki_comm); > >> > >> 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. > > p_comm[] in struct proc is only 20 bytes long (19 chars + nul), so you > can't make it bigger in kinfo_proc anyway as we only store 19 chars > in the kernel. (Note that we do have room to grow char arrays if > needed without having to completely rototill though; we use a hack to > store the "rest" of the thread name in a separate array to export the > full 19 chars of the thread name now.) > > If you want the raw command line you can't get that via kinfo_proc. > You can use the kern.proc.args sysctl or wrapper functions like > kvm_getargv() or procstat_getargv(). You can then use argv[0] as the > command name instead. > Thanks for your suggestion. I've tried that out and it does seem to work. However, I'm slightly confused by the fact that procstat_getargv() returns only command name and not the whole argv line, as function's name suggests. Here is my code: int main(int argc, char* argv[]) { kvm_t * kvm = kvm_open(nullptr, "/dev/null", nullptr, O_RDONLY, ""); int cnt; struct kinfo_proc * kp = kvm_getprocs(kvm, KERN_PROC_PID, getpid(), &cnt); struct procstat * ps = procstat_open_sysctl(); char ** argv0 = procstat_getargv(ps, kp, 0); puts(*argv0); procstat_close(ps); kvm_close(kvm); return 0; } Running "veryveryverylongcommandname" correctly produces "veryveryverylongcommandname" line on stdout, but "veryveryverylongcommandname args args args" also gives only "veryveryverylongcommandname". Is this correct behavior or am I missing something? > -- > John Baldwin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >