Re: toolchain/57075 (nbctfmerge looped)

[Luke Mewburn <luke%mewburn.net@localhost>]

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

From: Luke Mewburn <luke%mewburn.net@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: toolchain-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost, Andreas Gustafsson <gson%gson.org@localhost>
Subject: Re: toolchain/57075 (nbctfmerge looped)
Date: Fri, 26 May 2023 01:35:03 +1000

 On 23-05-25 15:10, Andreas Gustafsson wrote:
   |  lukem%NetBSD.org@localhost wrote:
   |  > This may have been fixed by:
   |  >   https://mail-index.netbsd.org/source-changes-hg/2022/05/31/msg356307.html
   |  >
   |  > Have you seen this recently?
   |  
   |  I don't recall seeing it happen again.  But even if the bug was fixed
   |  by the referenced commit, it could still happen on the TNF testbeds
   |  since it affects the nbctfmerge tool, which is linked with the host
   |  libpthread and therefore may still have the bug even if the system
   |  being built doesn't.
 
 Whether or not this specific bug is fixed, as a matter of GNATS
 convention, do we hold up closing a bug after a fix because there might
 be a system with the old code still deployed?  This is a bit rhetorical,
 because we can't use that as our convention because we'd never close
 bugs!
 
 Regarding ctfmerge: given the previous lack of error handling/reporting
 in the concurrency / thread code in ctfmerge, and the bugs I found and
 fixed on at least one host (macOS) that were previously not obvious
 because of lack of error handling, I don't know if we get much value
 keeping open older ctfmerge tickets that relate to thread issues.
 
 Happy to read other opinions, of course.