From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Vibhav Pant Newsgroups: gmane.emacs.devel Subject: Re: feature/asan-gc-poisoning: Better memory checks using AddressSanitizer Date: Sun, 18 Dec 2022 01:38:33 +0530 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006b9ed005f00ba7b7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33896"; mail-complaints-to="usenet@ciao.gmane.io" To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 17 21:09:29 2022 Return-path: Envelope-to: ged-emacs-devel@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 1p6dUv-0008ik-IH for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Dec 2022 21:09:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p6dUL-00025u-My; Sat, 17 Dec 2022 15:08:53 -0500 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 1p6dUJ-00025j-KK for emacs-devel@gnu.org; Sat, 17 Dec 2022 15:08:51 -0500 Original-Received: from mail-qv1-xf2c.google.com ([2607:f8b0:4864:20::f2c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p6dUH-0003n0-Lv for emacs-devel@gnu.org; Sat, 17 Dec 2022 15:08:51 -0500 Original-Received: by mail-qv1-xf2c.google.com with SMTP id u10so3898294qvp.4 for ; Sat, 17 Dec 2022 12:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Cw2MNeqLA5EQGraye4si4ZQRhZEokaluPGIxQMVCcJA=; b=NYmioxfA2qhp91GApy7nr5VJQEMvWYu8FpGkNH8hkfG+QSOtiuhaVY7CM3ZFwVNcoP 9phCsDpnSec23I8t/DBK7Q0qgIBPenyRD9VCvor9t/ZlRUeGngnAKp5IS4ufCC73KOH4 iDFA29rtmcutTZF6RPCzGr4SlS4+WVBIcMDvRSK0I4iSaThX1RhL3+SIiZ1FoEGoKBYx nnPzheIS3M/4AKSDFRqLm/txMj3q52sQ1Y1emiHwqveR9b+wTVrmft/dufl5GImi4UGv zO/kh/WZnYPtfYVbaw5JeaUT6vGL9rxmES84+jaCn7B0JeVX+USL8XQv/R9GXnoXK0Q5 aFNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Cw2MNeqLA5EQGraye4si4ZQRhZEokaluPGIxQMVCcJA=; b=SFn26xhEXqAHDcm6JSM8+7DON8XCFeSj2xRrq6I9FwHDFzD2KWuRp/sWt42bBLqOeK 8YAlDGYN8V0S0Xl6JKqUG3AodAGiBTrlEqx3IIThbyNEZZwzinuS0gB/iS3H6IMIhybl vGPalVnAZCmIxg4CGfAfmIKFexqO7LpwfnJMgPcv7Yt+ebHyKOlEPER/6fYcsxLs9ejE HYFk9PGe3WHFZbISxHENuDRtJTRUhSds3miWiyV6u0b06k2nCrbsFw0ghzBs9o7YrkFB CPLcxy7ma8GK53jUOWC7W/Gs5ztaNZfV0t4lmzYQw5NZl9uOLDBgAuDpFZREXzMZvAvb jfxQ== X-Gm-Message-State: ANoB5pmRqC4fJ1g8bkngWly0KkdnjCTM9taVcLeNeQ6rbQkkNt6F8anA 92tYbdr8Ehq+u8wR23L+gFl7ZChmp0ps6wwoAJSxfAmHkgQ= X-Google-Smtp-Source: AA0mqf6bhTp+vTZdigsWAhbrHQ9CRme2BDdvGLP/gVw8PaSWPIly+kF6m3X4+wnYfIFfQ2JfIP3GTP54NDeC+WwP9os= X-Received: by 2002:a0c:ef0b:0:b0:4c6:e904:3582 with SMTP id t11-20020a0cef0b000000b004c6e9043582mr53520026qvr.112.1671307727706; Sat, 17 Dec 2022 12:08:47 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::f2c; envelope-from=vibhavp@gmail.com; helo=mail-qv1-xf2c.google.com 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:301583 Archived-At: --0000000000006b9ed005f00ba7b7 Content-Type: text/plain; charset="UTF-8" Unless there are any objections, I plan to merge this branch into master today. Thanks, Vibhav Vibhav Pant vibhavp@gmail.com On Tue, Dec 6, 2022, 02:05 Vibhav Pant wrote: > As part of trying to debug the deluge of GC borks in > scratch/comp-static-data, I took a slight detour through Emacs' memory > management code and the sanity checks that it optionally comes with. > The changes in feature/asan-gc-poisoning attempt to augment the > latter, specifically when Emacs is built with '-fsanitize=address'. > > When enabled, almost all memory management operations are instrumented > with calls to ASan's "(un)poisoning" functions, which allow ASan to > mark allocated but not freed addresses as "poisoned", triggering > errors whenever they have been accessed. The idea behind this is to > add another layer of checks against code that makes use of free lists > and arena based allocators, only allowing access to regions of the > memory that are actually intended to be accessible (aka "unpoisoned" > in ASan parlance) by non alloc-related C code. An instance of this is > any object on a free list, or a vectorlike with the type PVEC_FREE (we > do abort whenever we come across such a vector, but this ideally > catches the bug way earlier in the flow, and therefore closer to the > source of the actual problem). Additional documentation explaining > this feature is available both on src/alloc.c and the "Running Emacs > with address sanitization" section in etc/DEBUG. > > The branch bootstraps successfully both with native-comp enabled and > disabled, and passes everything on the test suite on my machine. > Because enabling Address Sanitizer comes with a significant > performance + memory overhead, using it as a daily driver isn't > without a decent bit of sluggishness, although building with -O2 and > native compilation seems to help, at least a little. > I plan to get install this in `master` soon, so both feedback and > testing from other users would be greatly appreciated. The current > codebase quite likely does everything alloc related correctly, so an > ASan error might be indicative of a snag in this branch instead of > Emacs itself (fingers crossed for the opposite, however :)). > > Thanks, > Vibhav > -- > Vibhav Pant > vibhavp@gmail.com > GPG: 7ED1 D48C 513C A024 BE3A 785F E3FB 28CB 6AB5 9598 > --0000000000006b9ed005f00ba7b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Unless there are any objections, I plan= to merge this branch into master today.=C2=A0

<= /div>
Thanks,
Vibhav


On Tue, Dec 6, 2022= , 02:05 Vibhav Pant <vibhavp@gmail.= com> wrote:
As part of tryin= g to debug the deluge of GC borks in
scratch/comp-static-data, I took a slight detour through Emacs' memory<= br> management code and the sanity checks that it optionally comes with.
The changes in feature/asan-gc-poisoning attempt to augment the
latter, specifically when Emacs is built with '-fsanitize=3Daddress'= ;.

When enabled, almost all memory management operations are instrumented
with calls to ASan's "(un)poisoning" functions, which allow A= San to
mark allocated but not freed addresses as "poisoned", triggering<= br> errors whenever they have been accessed. The idea behind this is to
add another layer of checks against code that makes use of free lists
and arena based allocators, only allowing access to regions of the
memory that are actually intended to be accessible (aka "unpoisoned&qu= ot;
in ASan parlance) by non alloc-related C code. An instance of this is
any object on a free list, or a vectorlike with the type PVEC_FREE (we
do abort whenever we come across such a vector, but this ideally
catches the bug way earlier in the flow, and therefore closer to the
source of the actual problem). Additional documentation explaining
this feature is available both on src/alloc.c and the "Running Emacs with address sanitization" section in etc/DEBUG.

The branch bootstraps successfully both with native-comp enabled and
disabled, and passes everything on the test suite on my machine.
Because enabling Address Sanitizer comes with a significant
performance + memory overhead, using it as a daily driver isn't
without a decent bit of sluggishness, although building with -O2 and
native compilation seems to help, at least a little.
I plan to get install this in `master` soon, so both feedback and
testing from other users would be greatly appreciated. The current
codebase quite likely does everything alloc related correctly, so an
ASan error might be indicative of a snag in this branch instead of
Emacs itself (fingers crossed for the opposite, however :)).

Thanks,
Vibhav
--
Vibhav Pant
v= ibhavp@gmail.com
GPG: 7ED1 D48C 513C A024 BE3A=C2=A0 785F E3FB 28CB 6AB5 9598
--0000000000006b9ed005f00ba7b7--