From nobody Tue Aug 27 22:03:41 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WthQG2j7Vz5MTPg for ; Tue, 27 Aug 2024 22:03:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4WthQF35VMz54hj for ; Tue, 27 Aug 2024 22:03:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 47RM3fFG008582; Wed, 28 Aug 2024 01:03:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 47RM3fFG008582 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 47RM3fUU008573; Wed, 28 Aug 2024 01:03:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 28 Aug 2024 01:03:41 +0300 From: Konstantin Belousov To: fvalasiad Cc: "freebsd-hackers@freebsd.org" Subject: Re: Detecting the death of the last LWP of a tracee process. Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.87 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.87)[-0.870]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; MIME_TRACE(0.00)[0:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCPT_COUNT_TWO(0.00)[2]; MISSING_XM_UA(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4WthQF35VMz54hj On Wed, Aug 28, 2024 at 12:52:09AM +0300, Konstantin Belousov wrote: > On Tue, Aug 27, 2024 at 09:38:30PM +0000, fvalasiad wrote: > > Hello everyone! > > > > I am porting my so far linux-only FOSS project [build recorder](https://github.com/fvalasiad/build-recorder) to FreeBSD "unofficially", as if, in my own personal fork and not the parent organization's upstream repository. > > All for fun in my personal time, uncertain if and when it's gonna be merged upstream. > > > > As you can probably guess it utilizes ptrace(2), and I am facing some issues with it. > > > > manpage states this about the PTRACE_LWP flag: > > > > > Note that new processes do not report an event for > > > the creation of their initial thread, and exiting > > > processes do not report an event for the termination > > > of the last thread. > > > > This is kind of a bummer for my tool's needs. In case anyone is unfamiliar with threads in linux, they are essentially processes and there is no distinction between them. Trying to minimize the conditional compilation of my project to make maintaining it easier, I took > > advantage of the fact that LWPs have unique system-wide IDs, almost completely > > ignoring the distinction amongst processes and LWPs in my tool.... > > > > This though ruins everything, as I cannot properly clean the process' last LWP state > > without knowing its ID upon exit. Manpage states that you should do that through normal > > process signals, but once the process sends the WEXITED signal, the process and all info > > with it(namely, its last LWP's ID) is gone. Curious if there is a workaround besides adding > > extra state. > When waitpid(2) reports the process exit, you should have only one LWP left > in your registry of the process' threads. Clean it. Slight correction: process can exit with more than one thread still running. You should clean all threads belonging to the exited process. > > > > > Additionally, if anyone could help explain what PT_GET_SC_RET's double return value is all about. How can a traditional system call like open(2) have two return values? > > Some syscalls return two values, e.q. pipe(2), which needs to return fds > for in and out pipes. Less visible, fork(2) returns zero for child process, > but also the parent pid as an additional value, not exposed by C wrapper. > > On 32bit arches, lseek(2) needs to return 64bit result, which requires > two registers. Same for read(2)/write(2).