Received: (at 76393) by debbugs.gnu.org; 19 Feb 2025 12:18:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 19 07:18:42 2025 Received: from localhost ([127.0.0.1]:44246 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tkj2H-0000Mi-9k for submit <at> debbugs.gnu.org; Wed, 19 Feb 2025 07:18:42 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:57033) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tkj2F-0000Ln-2R for 76393 <at> debbugs.gnu.org; Wed, 19 Feb 2025 07:18:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739967512; x=1740226712; bh=5MxRvt6xBbWnW2nOElE++BPzGZUeEOlMy61GDZpZmdw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=lB8BeF47euyDnuLp8ebc7N5KId7kOF6FU7j93f6zynVo8nNzc6CUiurvtgD8PoQI9 aDiEU/MGLenZpX6cBvmxr+hqaPz40YsKCUMP4HN7Bv1DxMsDl9fBpQvt7tlRbOXNjy 2R1zblF+HYcLgqkHv44SLyn+fo3AauYSiI92VZWgADV358h2xMDiDYWT6f6M3O/6No o6xLQAYtnxL5FaHdxDA0UBdMA9A1cxFumBtE0+DTD/UpfaIgf4R34/gGthWHte6IdC UtIE5r3vHQB/cU999WhJN1BkEomO8feGWcOX/v21vphDGdKPQNz3D2AIebkcKah41L 6SNU78hT3Fjog== Date: Wed, 19 Feb 2025 12:18:26 +0000 To: Paul Eggert <eggert@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#76393: Warn about -fsanitizer=address builds Message-ID: <87h64q5dss.fsf@HIDDEN> In-Reply-To: <54569684-b5a2-4313-9e38-925bdb36c31f@HIDDEN> References: <878qq35t63.fsf@HIDDEN> <86seob8ec3.fsf@HIDDEN> <878qq345lc.fsf@HIDDEN> <54569684-b5a2-4313-9e38-925bdb36c31f@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 5d4c83bf9b87569236f26d5d16c6228490bba51f MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76393 Cc: 76393 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) "Paul Eggert" <eggert@HIDDEN> writes: > On 2/18/25 07:48, Pip Cet wrote: >> Building Emacs with address sanitization can help debug memory-use >> -problems, such as freeing the same object twice. To use >> -AddressSanitizer with GCC and similar compilers, append >> +problems, such as freeing the same object twice. However, >> +-fsanitize=3Daddress also introduces bugs in the compiled code which ca= use >> +GC problems and phantom crashes, which do not always look like they're >> +caused by the address sanitizer. > > I don't see a GCC bug there. I understand the desire to be diplomatic here, and I'll adjust the patch accordingly, but I don't agree: fake stacks are a rashly-implemented manipulation, violating established ABI conventions, which will cause false positives which are then hard to debug because none of them are documented sufficiently, and the error messages provide no indication that the sanitizer is to blame. > What I see is an incompatibility with Emacs's garbage collector, a > collector which relies on several aspects of undefined behavior in > C. So I suggest changing the last three lines to something like this: The idea that any significant program can rely only on defined behavior of C is nice, but it's not even close to being true. > as the default behavior of -fsanitize=3Daddress is incompatible with > ordinary Emacs operation, it needs to be combined with other options. It is important to point out that these bugs do not mention the sanitizer in the crash report, and that the only "option" to make GCC generate correct code is an environment variable, which is error-prone and inconvenient. >> +ASAN_OPTIONS=3D'detect_stack_use_after_return=3D0,detect_leaks=3D0' in = the >> +environment to suppress diagnostics of minor memory leaks in Emacs, and >> +buggy code which relocates objects from the stack to the heap . For >> +example: > > Here, change "buggy code which relocates" to "to suppress relocation > of". Again, happy to make the change if the decision is to remain diplomatic here. If the option were "no_fake_stack=3D1", I'd agree. But the option isn't called that: there is no ASAN option to insist on a traditional stack, we can only disable the various "features" which incidentally violate traditional stack assumptions. Today, it's 'detect_stack_use_after_return', but there's no guarantee (or documentation) of that. > Also, omit the space before ".". Oops. I'd written more there :-) > Otherwise, it looks good. > > I've found -fsanitize=3Daddress to be verrrrry helpful when debugging > obscure memory problems, and it's good to document how to use it. Well, it hasn't worked for a while. > It would be even better if we changed Emacs so that ASAN_OPTIONS need > not contain set detect_stack_use_after_return=3D0, as that would help > detect more errors. -fsanitize=3Daddress has support for this sort of > thing; see its __asan_addr_is_in_fake_stack function. However, Emacs > currently doesn't use that support, so we must currently settle for > detect_stack_use_after_return=3D0. __asan_get_current_fake_stack is marked for removal in GCC, and it's not quite clear whether that comment applies to __asan_addr_is_in_fake_stack, too. However, I don't see how either function would help us detect all the fake stacks and their extents. There is an established API for split stacks, implemented by -fsplit-stack (Emacs doesn't support it by default, but I wrote a patch to add support, and it's not hard). ASAN doesn't use it, and the alternatives it provides are unusable, so I'm skeptical that it's a tool which is worth the significant effort to "support" it. Pip
bug-gnu-emacs@HIDDEN:bug#76393; Package emacs.
Full text available.Received: (at 76393) by debbugs.gnu.org; 19 Feb 2025 00:50:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 18 19:50:23 2025 Received: from localhost ([127.0.0.1]:36676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tkYIA-0005bC-WE for submit <at> debbugs.gnu.org; Tue, 18 Feb 2025 19:50:23 -0500 Received: from mail.cs.ucla.edu ([131.179.128.66]:37996) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eggert@HIDDEN>) id 1tkYI8-0005aO-My for 76393 <at> debbugs.gnu.org; Tue, 18 Feb 2025 19:50:21 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 1A2E83C00E8B0; Tue, 18 Feb 2025 16:50:15 -0800 (PST) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id k49g9CpmK-dm; Tue, 18 Feb 2025 16:50:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id BD10B3C00D1EE; Tue, 18 Feb 2025 16:50:14 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu BD10B3C00D1EE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1739926214; bh=gi6plFcO79kXG9RClXhQRQr/tEtd0dypKNnKq4lLKYA=; h=Message-ID:Date:MIME-Version:To:From; b=d5paepc8sxRij2J6pyCw6wjbjAcEVUMEVjXyDgpdQUwON/6Xm5Mcc/3JGgYzC2gQl l6ftRSWUaIQ+NxSmtSBEjf7e8nxNBHQLAMz/Ir/NQ4AkvgWN19Xmhs1oUn2cyLhDqS pIfA9K1Xym9DE1pJ2mHtOCcZv7yZxZNapYjcBqleTeDL+LiILCnyNQ2GBB+YNRciib Ejl5GscVcmZtv8JWvQcRkjZi+9AoiYuqTOcfOeu60nfGhD2gzZMQ1XqKV4floECoMv 71cwHgLmpw7+ux0qnS2rmO9BhdLaZ/bN4wA5al5gqJzQEu24M5wmjSN8L7umHnSSzf OsAs1OgKCfE7g== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 0OqnHRPW-EM9; Tue, 18 Feb 2025 16:50:14 -0800 (PST) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 9BBAA3C00E8B0; Tue, 18 Feb 2025 16:50:14 -0800 (PST) Message-ID: <54569684-b5a2-4313-9e38-925bdb36c31f@HIDDEN> Date: Tue, 18 Feb 2025 16:50:14 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#76393: Warn about -fsanitizer=address builds To: Pip Cet <pipcet@HIDDEN> References: <878qq35t63.fsf@HIDDEN> <86seob8ec3.fsf@HIDDEN> <878qq345lc.fsf@HIDDEN> Content-Language: en-US From: Paul Eggert <eggert@HIDDEN> Autocrypt: addr=eggert@HIDDEN; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBlQQTAQgAPwIbAwYLCQgHAwIGFQgCCQoLBBYCAwEC HgECF4AWIQR+N5Kp2Kz31jO8FYjtl+kOYqp+NAUCZiLOewUJHWQLDAAKCRDtl+kOYqp+NHGE D/9Wmbk+cAaQsYLPGBvyzIjZIRzo/V2p3ZwckVA1VEQivx5azu1cs86qDoVIe45AtwmKOvdV wTQd/QeglkZR6D2YPW7UR/7emajyJZZcy+etVTDKoaw1i6/hmd/CpGjUeUSvgoPs6nYR+1lo pSXTpaGrh1W0qQHalSkOOwCHG3HtGk9Ve2AERDUYxmcn8/eZHb7xpUJEJMBBI1bx/zcw1EtB rjsQ1R1faJ/r/7LPAyV36RLvnbX69PylHKQEbJoaY9aUb2Vpm63ni3FeTA7/3jpPvaSRWHJh vPYx6Fm2Ln8pI0Yf/W2B8QMiPTnF/LnH2kvUcf9VXm+1mQJ3fBFU25HZwBhuqZ24IeKymPEt BUMQAum97Dto0jSgR2OUvX7z+twhpQEgRGBzPHYwDi4SxF5Z4Q5Y7B7a++HP9tIxG6CVFIwI 4xVaZud18bPa0YBL+cISmMgxq7h7yoVXl6u3pm9Yiv+W6Lp9QGN8Rw1VuJMOoFCYuoxG8mXO TA5b1jvlQ32gHFFhqErDAhNJRsfgrpe9Gok4Ycp+rWljbvS5Wrl0uth5MP7FbaHN2kmTZibq KXAd//IqczhDyU6qnW6ao+h4iDBDgYgRbQjmToX/vmIdEMzvPGqWXKhe/q1TYMuOO+IfP+bI fyPFH29nVN/o9c4J7myeKvv3HKSXdSVjlh2V787BTQRMgHJkARAApoXrvxP3DIfjCNOtXU/P dwMShKdX/RlSs5PfunV1wbKP8herXHrvQdFVqECaTSxmlhzbk8X0PkY9gcVaU2O49T3qsOd1 cHeF52YFGEt0LhsBeMjgNX5uZ1V76r8gyeVlFpWWb0SIwJUBHrDXexF67upeRb2vdHBjYDNe ySn+0B7gFEqvVmZu+LadudDp6kQLjatFvHQHUSGNshBnkkcaTbiI9Pst0GCc2aiznBiPPA2W QxAPlPRh3OGTsn5THADmbjqY6FEMLasVX8DSCblMvLwNeO/8SxziBidhqLpJCqdQRWHku5Xx gIkGeKOz5OLDvXHWJyafrEYjjkS6Ak6B5z6svKliClWnjHQcjlPzyoFFgKTEfcqDxCj4RY0D 0DgtFD0NfyeOidrSB/SzTe2hwryQE3rpSiqo+0cGdzh4yAHKYJ+UrXZ4p93ZhjGfKD1xlrNY DlWyW9PGmbvqFuDmiIAQf9WD/wzEfICc+F+uDDI+uYkRxUFp92ykmdhDEFg1yjYsU8iGU69a Hyvhq36z4zctvbqhRNzOWB1bVJ/dIMDvsExGcXQVDIT7sDNXv0wE3jKSKpp7NDG1oXUXL+2+ SF99Kjy753AbQSAmH617fyBNwhJWvQYg+mUvPpiGOtses9EXUI3lS4v0MEaPG43flEs1UR+1 rpFQWVHo1y1OO+sAEQEAAcLBfAQYAQgAJgIbDBYhBH43kqnYrPfWM7wViO2X6Q5iqn40BQJm Is58BQkdZAsMAAoJEO2X6Q5iqn40Q68QAJ9GubS/ej30Vc4idoZdc0IyMcL7kQJbMohF+Tyn ZE+TGn9WvzP10yLyzoI0vNlcNfP92d2MS//pFjOuANb5mwyiEYA+rDZIdS4ZZpHxCs2sxMC4 afLCf3kv4aMnTeBvb9na403dlczz9cAacvsmniSFdpb1+BzMpYbybglU5oYMGhYT2nnCRjXN 6S2nKYt4mjJeeOuxHrdeqQQdVBNYeNfTcPePeqvZ2+bD6u9yxZtaV+wxdpqglosQvjqhOYz7 h50/ZTSq70/npoCq44TzdJKttaYvlW6ziRz0g4RRAqZyoxjYXiy5qj8r8zXJuB11ApZCGuKn /usbji9RYbflAhxFeh4LMmpDVi6BrF30b73Md59K7PuEKN1NxzlWiqqQHZZ9momN0GXLPcGq 4uyfq7yVEy7wP5PMOh6oqscKklE3gFQtq0P1Ki0xqdF6Fq5LPJc+0Db2CYkVIy7Xaa/f74I3 sOfQfEeDylVXR5iDfUJEYv/0DYhOr7q5/0b1kh3M4wkrB4C5jVNHjIIj+RsAK90c3t38OhAl jiSN7Bkwy24Afy8eIu6wWzvhnsQGpZPB+IffmxT1wkTy8UxZKjUWV0C82iphVgCUUi2f9sDV Q/tNcwVWmOS+gdv9Wk6tdGeM+Ee+Qs6YG05jcSoajzF0TL07ajLcayRq2j1Os2CtQ8qu Organization: UCLA Computer Science Department In-Reply-To: <878qq345lc.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76393 Cc: 76393 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2/18/25 07:48, Pip Cet wrote: > Building Emacs with address sanitization can help debug memory-use > -problems, such as freeing the same object twice. To use > -AddressSanitizer with GCC and similar compilers, append > +problems, such as freeing the same object twice. However, > +-fsanitize=address also introduces bugs in the compiled code which cause > +GC problems and phantom crashes, which do not always look like they're > +caused by the address sanitizer. I don't see a GCC bug there. What I see is an incompatibility with Emacs's garbage collector, a collector which relies on several aspects of undefined behavior in C. So I suggest changing the last three lines to something like this: as the default behavior of -fsanitize=address is incompatible with ordinary Emacs operation, it needs to be combined with other options. > +ASAN_OPTIONS='detect_stack_use_after_return=0,detect_leaks=0' in the > +environment to suppress diagnostics of minor memory leaks in Emacs, and > +buggy code which relocates objects from the stack to the heap . For > +example: Here, change "buggy code which relocates" to "to suppress relocation of". Also, omit the space before ".". Otherwise, it looks good. I've found -fsanitize=address to be verrrrry helpful when debugging obscure memory problems, and it's good to document how to use it. It would be even better if we changed Emacs so that ASAN_OPTIONS need not contain set detect_stack_use_after_return=0, as that would help detect more errors. -fsanitize=address has support for this sort of thing; see its __asan_addr_is_in_fake_stack function. However, Emacs currently doesn't use that support, so we must currently settle for detect_stack_use_after_return=0.
bug-gnu-emacs@HIDDEN:bug#76393; Package emacs.
Full text available.Received: (at 76393) by debbugs.gnu.org; 18 Feb 2025 19:35:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 18 14:35:35 2025 Received: from localhost ([127.0.0.1]:33576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tkTNW-0007ar-TZ for submit <at> debbugs.gnu.org; Tue, 18 Feb 2025 14:35:35 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39926) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tkTNV-0007aD-0F for 76393 <at> debbugs.gnu.org; Tue, 18 Feb 2025 14:35:33 -0500 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 <eliz@HIDDEN>) id 1tkTNO-0007oz-5u; Tue, 18 Feb 2025 14:35:26 -0500 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=d08wsSFOvicjGflK857QxEraSCuWk81I9AxkJ9TESuk=; b=nCg1GJmwKDCl 95CGKZPteTdp799ep3ccc6+dGigrOCznBALkPrxpJDSB0xjBtM7eY60kZiN7Kf/NHAYOwGlJJSkY2 2ODse9T5nuGTKyNapbeB9pUU2Ck2QOtnwlkN+HEEaK33FPXJEzLWLwiUkCawmjRYknm4WnA8HDxhq z7k3beJWCnDulwtcwXeTX2atTraSfpBaleJHnRU/Pi+PC7SB+UW4ajux7ozJiDODNTvEQw+V07FkX tPoMwLD+TnHwJE8FvTY5/h8X4WEwuEIlij6Zd3cLSnSm96sqkv8SSzm4CLtwiw+WJxID1FG8gJeVL zUEGLJObLfDF87PSbylBgA==; Date: Tue, 18 Feb 2025 21:35:23 +0200 Message-Id: <865xl782ro.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <8734gb415t.fsf@HIDDEN> (message from Pip Cet on Tue, 18 Feb 2025 17:24:26 +0000) Subject: Re: bug#76393: Warn about -fsanitizer=address builds References: <878qq35t63.fsf@HIDDEN> <86seob8ec3.fsf@HIDDEN> <878qq345lc.fsf@HIDDEN> <86frkb89k6.fsf@HIDDEN> <8734gb415t.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76393 Cc: 76393 <at> debbugs.gnu.org, eggert@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Tue, 18 Feb 2025 17:24:26 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: eggert@HIDDEN, 76393 <at> debbugs.gnu.org > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > > When you say "bugs in compiled code", do you mean the code in the > > Emacs executable, or do you mean the bytecode or native code emitted > > The code put by GCC -fanalyzer into the Emacs executable does buggy > things unless an environment variable is set to make it not do those > things. > > > by compiling Lisp? If the former, isn't that a GCC bug? And if so, > > It is, yes: GCC violates the unwritten contract by which conservative GC > works when compiling with -fanalyze=address, by moving stack structs to the > heap. > > > perhaps there are some -fSOMETHING switches which avoid hitting those > > bugs? > > -fno-analyze=address? Ideally, GCC should be passed by Emacs an option > to ensure it won't break conservative GC, but I'm not aware of such an > option. I'm not familiar with -fanalyze=address. Does disabling it still allow to use address sanitization? if so, perhaps we should recommend using -fno-analyze=address when building for ASAN?
bug-gnu-emacs@HIDDEN:bug#76393; Package emacs.
Full text available.Received: (at 76393) by debbugs.gnu.org; 18 Feb 2025 17:24:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 18 12:24:41 2025 Received: from localhost ([127.0.0.1]:60458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tkRKq-0001FY-Tg for submit <at> debbugs.gnu.org; Tue, 18 Feb 2025 12:24:41 -0500 Received: from mail-40131.protonmail.ch ([185.70.40.131]:36225) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tkRKp-0001Ew-4v for 76393 <at> debbugs.gnu.org; Tue, 18 Feb 2025 12:24:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739899472; x=1740158672; bh=QqFNHW15zUKRkjth0OYHlweT7RP+d0ows0v+z7IPwHY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=AZa2VoZVZbvkKMhgRlAVfleKsW5GxVK8AFVOuu0Y/uM64FQLjmtrgLsfgjBeYVtrQ RmFg6woESDKur6cr+2ZOlOqG0wKdpAnlEWSJe3rsvIzpeqFCR23gnvOZpS151x7VdY /o6rnf+IcS0YaFiG/9jA/hYPZeZKVOtRQOpc/6M6jbHV/EBzpA6P39b1l8jwoCJyXJ gi8FXphqzbkB0IgHlo1EHQ91MA3uCmok93fSNJFw9ikl+ZckB39E7bLHoMJbkIy6lP zxCIKh9zU6QmFjvO3DwaTEbao6DQw+5R0AUFTmNGKi0aEkodvVkc7RP7IiuX1X/HNT IPgQVWqumJW9g== Date: Tue, 18 Feb 2025 17:24:26 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#76393: Warn about -fsanitizer=address builds Message-ID: <8734gb415t.fsf@HIDDEN> In-Reply-To: <86frkb89k6.fsf@HIDDEN> References: <878qq35t63.fsf@HIDDEN> <86seob8ec3.fsf@HIDDEN> <878qq345lc.fsf@HIDDEN> <86frkb89k6.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: d4380644bcc3251ebacfdaa2607363750ce6d0b1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76393 Cc: 76393 <at> debbugs.gnu.org, eggert@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Tue, 18 Feb 2025 15:48:44 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: 76393 <at> debbugs.gnu.org, eggert@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> > If what we have in etc/DEBUG about building with address sanitization >> > is not enough or outdated, please consider updating and expanding that >> > section. >> >> Since we detect asan builds, and we know them to be broken, we should >> probably warn about it in configure.ac as well. I strongly suspect that >> if ASAN sees further development, it will break Emacs in new ways, and >> that'll be hard to debug. > > I think it's too early for that. I don't see enough people using such > builds, so I think for now having that in etc/DEBUG is enough. > There's no need to complicate everyone's life because one or two > people want sometimes to use ASAN. Okay, Paul's opinion would definitely be appreciated. >> So here's the documentation part; I'd like to change configure.ac as >> well, but the doc part should come first. > > LGTM in general, with one question below. But I'd like to hear Paul's > opinion on this as well. Sure, no rush here. >> Building Emacs with address sanitization can help debug memory-use >> -problems, such as freeing the same object twice. To use >> -AddressSanitizer with GCC and similar compilers, append >> +problems, such as freeing the same object twice. However, >> +-fsanitize=3Daddress also introduces bugs in the compiled code which ca= use >> +GC problems and phantom crashes, which do not always look like they're >> +caused by the address sanitizer. > > When you say "bugs in compiled code", do you mean the code in the > Emacs executable, or do you mean the bytecode or native code emitted The code put by GCC -fanalyzer into the Emacs executable does buggy things unless an environment variable is set to make it not do those things. > by compiling Lisp? If the former, isn't that a GCC bug? And if so, It is, yes: GCC violates the unwritten contract by which conservative GC works when compiling with -fanalyze=3Daddress, by moving stack structs to t= he heap. > perhaps there are some -fSOMETHING switches which avoid hitting those > bugs? -fno-analyze=3Daddress? Ideally, GCC should be passed by Emacs an option to ensure it won't break conservative GC, but I'm not aware of such an option. Pip
bug-gnu-emacs@HIDDEN:bug#76393; Package emacs.
Full text available.Received: (at 76393) by debbugs.gnu.org; 18 Feb 2025 17:09:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 18 12:09:10 2025 Received: from localhost ([127.0.0.1]:60206 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tkR5p-0007zE-HY for submit <at> debbugs.gnu.org; Tue, 18 Feb 2025 12:09:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44766) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tkR5X-0007w3-De for 76393 <at> debbugs.gnu.org; Tue, 18 Feb 2025 12:08:52 -0500 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 <eliz@HIDDEN>) id 1tkR5R-00068Y-8l; Tue, 18 Feb 2025 12:08:45 -0500 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=n0dbcCTV0zeo0UyO0TQrO6p7TslH5wl9iv7EexP8BSs=; b=P6kmVNsNIJlN vrAr7Uc5ZgPpxk8bowL0BfKNOEgE370BQD5vksC5Fog/lubdUoaMU4d3ZXAuH2nwsCBQW9HS4yd56 d6PO8Wouv5vBPpIvlO/LngP22LIRhOr5KQm9GKH07pgSa31MZ1Mr22HZcUICzuo85A2h2PWtqjSOW kIYvUtOgMKYyJx0hZfIzNAIEKpsaUXCN7evMtfHVVMAn7UxIYv8M7Z+XnFLb1bPB+9uB0aEk56BDH nos569S7Ca2LuBBHEwofTJG3P4E+3xHa3kU3dddNovOxjqz2b7prGPPTlLevlaDQXXOqjNJQQ/lqH x0d+WCkGr0ceff3Ba7u7/A==; Date: Tue, 18 Feb 2025 19:08:41 +0200 Message-Id: <86frkb89k6.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN>, eggert@HIDDEN In-Reply-To: <878qq345lc.fsf@HIDDEN> (message from Pip Cet on Tue, 18 Feb 2025 15:48:44 +0000) Subject: Re: bug#76393: Warn about -fsanitizer=address builds References: <878qq35t63.fsf@HIDDEN> <86seob8ec3.fsf@HIDDEN> <878qq345lc.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76393 Cc: 76393 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Tue, 18 Feb 2025 15:48:44 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: 76393 <at> debbugs.gnu.org, eggert@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > > If what we have in etc/DEBUG about building with address sanitization > > is not enough or outdated, please consider updating and expanding that > > section. > > Since we detect asan builds, and we know them to be broken, we should > probably warn about it in configure.ac as well. I strongly suspect that > if ASAN sees further development, it will break Emacs in new ways, and > that'll be hard to debug. I think it's too early for that. I don't see enough people using such builds, so I think for now having that in etc/DEBUG is enough. There's no need to complicate everyone's life because one or two people want sometimes to use ASAN. > So here's the documentation part; I'd like to change configure.ac as > well, but the doc part should come first. LGTM in general, with one question below. But I'd like to hear Paul's opinion on this as well. > Building Emacs with address sanitization can help debug memory-use > -problems, such as freeing the same object twice. To use > -AddressSanitizer with GCC and similar compilers, append > +problems, such as freeing the same object twice. However, > +-fsanitize=address also introduces bugs in the compiled code which cause > +GC problems and phantom crashes, which do not always look like they're > +caused by the address sanitizer. When you say "bugs in compiled code", do you mean the code in the Emacs executable, or do you mean the bytecode or native code emitted by compiling Lisp? If the former, isn't that a GCC bug? And if so, perhaps there are some -fSOMETHING switches which avoid hitting those bugs?
bug-gnu-emacs@HIDDEN:bug#76393; Package emacs.
Full text available.Received: (at 76393) by debbugs.gnu.org; 18 Feb 2025 15:49:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 18 10:49:02 2025 Received: from localhost ([127.0.0.1]:59276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tkPqI-0001KL-0G for submit <at> debbugs.gnu.org; Tue, 18 Feb 2025 10:49:02 -0500 Received: from mail-40133.protonmail.ch ([185.70.40.133]:37115) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tkPqE-0001Jj-JL for 76393 <at> debbugs.gnu.org; Tue, 18 Feb 2025 10:48:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739893731; x=1740152931; bh=MLptODbWBlq1IeUNnlHA5AkbXI8lUwW3Mra5BHTC/Q4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=lzmvJIPZfIO9NdvFWbKMudidj5jIi+j0qfMRHgvl5VhTxjFfHJaSg2MQ9FqKTzR9Y fIKrRlQf0ZQiijXDkeYRhLgSeV7+SGVvQ1jBnNCVA+C4VJtyi0+/ds3Mv9XCEjJgEE XkOwO+yjakFDH23kyUSJqNcB+rnLgQA0aMFe8zoYX1cH/pplF8cFLiultn/kDXf+sY baGpiU9LWPaLT01pHwPr5iyxMTq63dUgFZ3W01eMVd4p7xwMB2ilGvEneOdhWdoGvU G6JKevcgG6qFelKK7kvouH+puhTWK7J9YGyDpjjN4hsR+OkRjaZXq8Y6/+qqR5eeVj 41HOXzusx1W+Q== Date: Tue, 18 Feb 2025 15:48:44 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#76393: Warn about -fsanitizer=address builds Message-ID: <878qq345lc.fsf@HIDDEN> In-Reply-To: <86seob8ec3.fsf@HIDDEN> References: <878qq35t63.fsf@HIDDEN> <86seob8ec3.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: ca4f75c9fc08b4af44b7d6950d508326ca83f2f7 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 76393 Cc: 76393 <at> debbugs.gnu.org, eggert@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Tue, 18 Feb 2025 12:34:08 +0000 >> From: Pip Cet via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> Building with current GCC and -fsanitizer=3Daddress results in certain >> (large) stack allocations being performed on a "fake stack", using >> __asan_stack_malloc_N. This "fake stack" is invisible to GC and thus >> breaks conservative GC scanning (bug#76327). >> >> It seems to be possible to work around this by setting >> >> ASAN_OPTIONS=3Ddetect_stack_use_after_return=3D0 >> >> Even with that option, a "sanitized" build reports bogus errors. >> >> ASAN_OPTIONS=3Ddetect_stack_use_after_return=3D0,detect_leaks=3D0 >> >> seems to work, at least, but is it really worth it to keep adding >> options (inconveniently using environment variables) to work around such >> ASAN bugs? >> >> I think it would be preferrable to warn about builds with >> -fsanitizer=3Daddress, which generates broken code, or disable them >> entirely. > > If what we have in etc/DEBUG about building with address sanitization > is not enough or outdated, please consider updating and expanding that > section. Since we detect asan builds, and we know them to be broken, we should probably warn about it in configure.ac as well. I strongly suspect that if ASAN sees further development, it will break Emacs in new ways, and that'll be hard to debug. So here's the documentation part; I'd like to change configure.ac as well, but the doc part should come first. From 96e3e05a8a636b205ba204a222dc2eb98a45d4fa Mon Sep 17 00:00:00 2001 From: Pip Cet <pipcet@HIDDEN> Subject: [PATCH] Warn about -fsanitize=3Daddress (bug#76393) * etc/DEBUG (Running Emacs with address sanitization): Explain currently-known problems when building with -fsanitize=3Daddress. --- etc/DEBUG | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/etc/DEBUG b/etc/DEBUG index ca061063454..95c2180fb18 100644 --- a/etc/DEBUG +++ b/etc/DEBUG @@ -1010,14 +1010,20 @@ program. ** Running Emacs with address sanitization =20 Building Emacs with address sanitization can help debug memory-use -problems, such as freeing the same object twice. To use -AddressSanitizer with GCC and similar compilers, append +problems, such as freeing the same object twice. However, +-fsanitize=3Daddress also introduces bugs in the compiled code which cause +GC problems and phantom crashes, which do not always look like they're +caused by the address sanitizer. + +To use AddressSanitizer with GCC and similar compilers, append '-fsanitize=3Daddress' to CFLAGS, either when running 'configure' or running 'make'. Configure, build and run Emacs with -ASAN_OPTIONS=3D'detect_leaks=3D0' in the environment to suppress -diagnostics of minor memory leaks in Emacs. For example: +ASAN_OPTIONS=3D'detect_stack_use_after_return=3D0,detect_leaks=3D0' in the +environment to suppress diagnostics of minor memory leaks in Emacs, and +buggy code which relocates objects from the stack to the heap . For +example: =20 - export ASAN_OPTIONS=3D'detect_leaks=3D0' + export ASAN_OPTIONS=3D'detect_stack_use_after_return=3D0,detect_leaks=3D= 0' ./configure CFLAGS=3D'-O0 -g3 -fsanitize=3Daddress' make src/emacs --=20 2.48.1 Pip
bug-gnu-emacs@HIDDEN:bug#76393; Package emacs.
Full text available.Received: (at 76393) by debbugs.gnu.org; 18 Feb 2025 15:25:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 18 10:25:47 2025 Received: from localhost ([127.0.0.1]:59129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tkPTm-0007hE-GA for submit <at> debbugs.gnu.org; Tue, 18 Feb 2025 10:25:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51726) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tkPTj-0007gc-RB for 76393 <at> debbugs.gnu.org; Tue, 18 Feb 2025 10:25:44 -0500 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 <eliz@HIDDEN>) id 1tkPTc-0007fR-QX; Tue, 18 Feb 2025 10:25:36 -0500 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=t174ZZBgPcZF7Qwr1kr483cSWCgclPqRViWzgCAUm6k=; b=SJASMJaoRd6b UZuJZzSZwsLKph+g57KR3OWzm3MbQ39/rVUU7lDF1MczzdXEN5HrmWnOIpKJjqJSKZJGYMGO+7Q+M zJ4zQgRK3zAW4aePKA0nWp+lumWWXWb/b7DrcCEEkrjvWnUmgmXw9e6k4srTKoKtxUloTAt6q6CMC xn8kJOHxkOg/IgqNIpBiIIrEhKLyA6sO8tsg+5nTHRVLWhLqRT9WHDnhnv+aTgGluNrAudbktx7/J 04jxdo57BeUGOM/raYLwv0zqb8lutKs6TjIh5sRGvmEnpX5i2quAM6XxUAF9NND1qtHVzqqgzDRkl 4lkbct7jk/AeqwdLtDNr6g==; Date: Tue, 18 Feb 2025 17:25:32 +0200 Message-Id: <86seob8ec3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <878qq35t63.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#76393: Warn about -fsanitizer=address builds References: <878qq35t63.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 76393 Cc: 76393 <at> debbugs.gnu.org, eggert@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Tue, 18 Feb 2025 12:34:08 +0000 > From: Pip Cet via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > Building with current GCC and -fsanitizer=address results in certain > (large) stack allocations being performed on a "fake stack", using > __asan_stack_malloc_N. This "fake stack" is invisible to GC and thus > breaks conservative GC scanning (bug#76327). > > It seems to be possible to work around this by setting > > ASAN_OPTIONS=detect_stack_use_after_return=0 > > Even with that option, a "sanitized" build reports bogus errors. > > ASAN_OPTIONS=detect_stack_use_after_return=0,detect_leaks=0 > > seems to work, at least, but is it really worth it to keep adding > options (inconveniently using environment variables) to work around such > ASAN bugs? > > I think it would be preferrable to warn about builds with > -fsanitizer=address, which generates broken code, or disable them > entirely. If what we have in etc/DEBUG about building with address sanitization is not enough or outdated, please consider updating and expanding that section.
bug-gnu-emacs@HIDDEN:bug#76393; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 18 Feb 2025 12:34:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 18 07:34:48 2025 Received: from localhost ([127.0.0.1]:56058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tkMoJ-0005cH-Jh for submit <at> debbugs.gnu.org; Tue, 18 Feb 2025 07:34:47 -0500 Received: from lists.gnu.org ([2001:470:142::17]:56918) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tkMoD-0005b7-LQ for submit <at> debbugs.gnu.org; Tue, 18 Feb 2025 07:34:45 -0500 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 <pipcet@HIDDEN>) id 1tkMo6-0006eA-LE for bug-gnu-emacs@HIDDEN; Tue, 18 Feb 2025 07:34:34 -0500 Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <pipcet@HIDDEN>) id 1tkMnz-0007zH-EY for bug-gnu-emacs@HIDDEN; Tue, 18 Feb 2025 07:34:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1739882053; x=1740141253; bh=ibhuRaEymDKAXLd+0i+BZqgE3m2SlqQzHLItEwjS0Ak=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=Idzhf9e7X8un1xa77ZbYTvDSMelGm8c49RHL6378KjgQyuIb0ZfcmOVEsQH/2oxBx XuHFVopt8q/Wgg/YAA0kbtAKexStX4bvfpLYzW2+Jg/HdlYEl36bFONjroyjugjpmD 0CJc8CupD+MzHS6xAPEvN/ahSiIK7VNyXdhoCDdUP5mnjmm6D7Q8MVNDdAETTOSLQx Fl2gQB3MgrhJ+tldx7txwXWfXxVuZDCkZPc6e7wAuSWVsz1nroukL08E/B9a53NWIR nJ0dFJtHXHUtlENunPvtwqfdZ/V6OXaSXuiSesb6FVp74+fRh2+p94kuMMh1z0bvak ybVBffQork1zA== Date: Tue, 18 Feb 2025 12:34:08 +0000 To: bug-gnu-emacs@HIDDEN, Paul Eggert <eggert@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Warn about -fsanitizer=address builds Message-ID: <878qq35t63.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: eefe99c64cc5d575296eb47740c9ede8ec4ee2f2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.134; envelope-from=pipcet@HIDDEN; helo=mail-40134.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) Building with current GCC and -fsanitizer=3Daddress results in certain (large) stack allocations being performed on a "fake stack", using __asan_stack_malloc_N. This "fake stack" is invisible to GC and thus breaks conservative GC scanning (bug#76327). It seems to be possible to work around this by setting ASAN_OPTIONS=3Ddetect_stack_use_after_return=3D0 Even with that option, a "sanitized" build reports bogus errors. ASAN_OPTIONS=3Ddetect_stack_use_after_return=3D0,detect_leaks=3D0 seems to work, at least, but is it really worth it to keep adding options (inconveniently using environment variables) to work around such ASAN bugs? I think it would be preferrable to warn about builds with -fsanitizer=3Daddress, which generates broken code, or disable them entirely.
Pip Cet <pipcet@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#76393; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.