From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#63752: 28.2; GCC 13.1 breaks Emacs subprocess handling when built with -D_FORTIFY_SOURCE Date: Thu, 06 Jul 2023 08:28:33 +0300 Message-ID: <83y1jtip6m.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18809"; mail-complaints-to="usenet@ciao.gmane.io" Cc: svraka.andras@gmail.com, 63752@debbugs.gnu.org To: Cyril Arnould , Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 06 07:29:44 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qHHYl-0004hP-Go for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Jul 2023 07:29:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHHYK-0001k5-5u; Thu, 06 Jul 2023 01:29:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHHY7-0001jg-PW for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2023 01:29:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qHHY7-0005GY-1L for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2023 01:29:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qHHY6-0000fw-BI for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2023 01:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Jul 2023 05:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63752 X-GNU-PR-Package: emacs Original-Received: via spool by 63752-submit@debbugs.gnu.org id=B63752.16886213222567 (code B ref 63752); Thu, 06 Jul 2023 05:29:02 +0000 Original-Received: (at 63752) by debbugs.gnu.org; 6 Jul 2023 05:28:42 +0000 Original-Received: from localhost ([127.0.0.1]:39274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHHXl-0000fL-Lq for submit@debbugs.gnu.org; Thu, 06 Jul 2023 01:28:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35614) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHHXj-0000f9-Nv for 63752@debbugs.gnu.org; Thu, 06 Jul 2023 01:28:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHHXe-0005E7-8z; Thu, 06 Jul 2023 01:28:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=5fX3IGjo7Zwd3PcEJNONZ1R74i/i2iY8ygJBOI11/b4=; b=H5Duj7Yg7zwP a1JNeYFMqvtAqG4lGcgYo+PsI0mrnv8tbTrbPAmjkZ4GpP+NhXQFMNh/IqE5TuqCdLVeqXtntdfqJ Mtq5PsU60MSoYk/s768qETdqRBd75aBw6jP75SsHxJ2o6lELCRlVf39QWMasTORULjxW18I9O4AQp BCXYyxmL6xlrJljMyPmVz/1dbYHTFnX4WNsXWf6oWWpH4XUM8yrD7aD37Q9ecHOxVCb97uAKOVugz x28Y8y4jjTAR82Bov1FuTX555Ighjh08iGauy2E/ZuM3CygHof68J/p1NY4w4inoLDI5uOeyM/jZE 2PbKI5Fv0muTqvqFwZmUVQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHHXd-00016Z-Fm; Thu, 06 Jul 2023 01:28:33 -0400 In-Reply-To: (message from Cyril Arnould on Wed, 5 Jul 2023 20:23:33 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:264651 Archived-At: > From: Cyril Arnould > CC: "63752@debbugs.gnu.org" <63752@debbugs.gnu.org>, "svraka.andras@gmail.com" > > Date: Wed, 5 Jul 2023 20:23:33 +0000 > > Thanks for the pointers! Following your advice, the first sysdep1.c with > code up until serial_open was working quite quickly. On a hunch, I've > singled out the emacs_intr_read function and got lucky: If I only put > the emacs_intr_read, emacs_read and emacs_read_quit functions into > sysdep1.c, the problems go away if sysdep1.o is compiled without > -D_FORTIFY_SOURCE=2. Thanks, I hope Andrea will have ideas after looking at the differences. There are several symbols in the diffs which are used only in the -D_FORTIFY_SOURCE=2 code, whose precise meanings are unclear to me. Those are the declaration qualifier __mingw_bos_extern_ovr and the functions __mingw_bos_ptr_chk_warn and __mingw_call__read. Under __MINGW_FORTIFY_LEVEL > 0 __mingw_bos_extern_ovr is defined like this: # define __mingw_bos_extern_ovr extern __inline__ __cdecl \ __attribute__((__always_inline__, __gnu_inline__)) \ __mingw_attribute_artificial Otherwise, it's defined to nothing. The above just controls the inlining, but that the 'artificial' attribute is described like this in the GCC manual: 'artificial' This attribute is useful for small inline wrappers that if possible should appear during debugging as a unit. Depending on the debug info format it either means marking the function as artificial or using the caller location for all instructions within the inlined body. I'm not sure I understand what this means in the context of the issue we are discussing here. The other 2 symbols seem to be about checking a pointer and calling '_read' while checking the pointer to the buffer passed to it. __mingw_bos_ptr_chk_warn is defined like this under __MINGW_FORTIFY_LEVEL > 0: # define __mingw_bos_ptr_chk_warn(p, n, maxtype) \ ((__mingw_bos_known(p) \ && __builtin_constant_p(__mingw_bos(p, maxtype) < (size_t)(n)) \ && __mingw_bos(p, maxtype) < (size_t)(n)) \ ? __mingw_chk_fail_warn() : __mingw_bos_ptr_chk(p, n, maxtype)) And here's __mingw_call__read: #define __MINGW_ASM_CRT_CALL(func) __asm__(__STRINGIFY(func)) _CRTIMP int __cdecl __mingw_call__read(int, void *, unsigned int) __MINGW_ASM_CRT_CALL(_read); AFAICT, __mingw_chk_fail_warn eventually does this: void __cdecl __attribute__((__noreturn__)) __chk_fail(void) { static const char msg[] = "*** buffer overflow detected ***: terminated\n"; write(STDERR_FILENO, msg, strlen(msg)); if (IsProcessorFeaturePresent(PF_FASTFAIL_AVAILABLE)) { __fastfail(FAST_FAIL_RANGE_CHECK_FAILURE); } else { TerminateProcess(GetCurrentProcess(), STATUS_STACK_BUFFER_OVERRUN); __builtin_unreachable(); } } Again, not sure what this means for the issue at hand. In particular, __fastfail emits "int 0x29", see https://learn.microsoft.com/en-us/cpp/intrinsics/fastfail?view=msvc-170 > Aside from those functions, sysdep1.c also contains all of the includes > of the original file; I figured it doesn't make much sense to narrow > those down further. I also had to add the MAX_RW_COUNT > definition. There's a patch attached; it can be tested as follows: Thanks, I hope Andrea will have some ideas. It's too bad the problem goes away under GDB, because we don't even know whether the crash is due to some fatal error in the Emacs code, or due to those extra-checking routines inserted into the code by the FORTIFY option. IOW, it could be that the problem happens because the FORTIFY routines don't understand something Emacs does and consider it a bug worthy of aborting the program. Another interesting question is why the problems happen only in Emacs built with native compilation. Do we use emacs_read or its callers in some special ways when they are called from comp.c or comp.el? Maybe we should ask the MinGW64 folks who implemented the FORTIFY support for MinGW64 GCC to join this discussion and help us figure out which part(s) of this puzzle are relevant and why? Cyril, can you reach out to them and ask them help us out here? There are too many unknowns here, and having someone on board who understands what the various FORTIFY additions mean and do, and perhaps also how to selectively disable them (to find the one that really matters) will definitely help. Thanks. P.S. Please keep ANdrea CC'd on this discussion.