From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18851 invoked from network); 29 Sep 2020 20:34:25 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 29 Sep 2020 20:34:25 -0000 Received: (qmail 24473 invoked by uid 550); 29 Sep 2020 20:34:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24455 invoked from network); 29 Sep 2020 20:34:22 -0000 Date: Tue, 29 Sep 2020 16:34:07 -0400 From: Rich Felker To: Jesse Hathaway Cc: musl@lists.openwall.com Message-ID: <20200929203407.GH17637@brightrain.aerifal.cx> References: <20200929183644.GE17637@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: Pending patches for MT-fork stuff On Tue, Sep 29, 2020 at 01:51:30PM -0500, Jesse Hathaway wrote: > On Tue, Sep 29, 2020 at 1:36 PM Rich Felker wrote: > > Can you provide an strace (with -f) showing the hang? It's probably > > not related to this since fork does not seem to be involved. Depending > > on how you're using Go, it may just be Go bypassing libc then trying > > to use libc functions, which at least used to be a big problem; I > > don't know if it's fixed nowadays or not. > > Thanks Rich, for taking a look, I have attached an strace of the > program compiled against musl & glibc. The first call to setreuid > succeeds in both, but the second call fails under musl. Jesse The problem is this line: > 8238 rt_sigprocmask(SIG_SETMASK, ~[HUP INT QUIT ILL TRAP ABRT BUS FPE SEGV TERM STKFLT CHLD PROF SYS RTMIN RT_1], Something broken in the Go runtime is bypassing libc and either calling SYS_rt_sigprocmask itself, or calling the libc sigprocmask function with a sigset_t it produced itself, blocking a libc-internal signal. This makes it invalid to make any further use of libc. Either it (the Go runtime) needs to manipulate sigset_t objects via the public APIs for them (sigfillset, sigaddset, etc.) or its wrapper for sigprocmask needs to convert the Go-manipulated sigset_t to one valid for libc by iterating over the bits and using sigaddset, so that invalid bits don't end up in the one passed to libc. Rich