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#61960: 30.0.50; Unexec build reliably crashes during loadup Date: Sun, 02 Jul 2023 08:52:18 +0300 Message-ID: <835y72q2r1.fsf@gnu.org> References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7552"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61960@debbugs.gnu.org To: Konstantin Kharlamov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 02 07:52:25 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 1qFq0X-0001hj-FC for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 02 Jul 2023 07:52:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qFq0C-0002pU-FF; Sun, 02 Jul 2023 01:52:04 -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 1qFq0A-0002mG-Ho for bug-gnu-emacs@gnu.org; Sun, 02 Jul 2023 01:52:02 -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 1qFq0A-0000mf-0v for bug-gnu-emacs@gnu.org; Sun, 02 Jul 2023 01:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qFq09-0005dN-Sy for bug-gnu-emacs@gnu.org; Sun, 02 Jul 2023 01:52:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Jul 2023 05:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61960 X-GNU-PR-Package: emacs Original-Received: via spool by 61960-submit@debbugs.gnu.org id=B61960.168827711621646 (code B ref 61960); Sun, 02 Jul 2023 05:52:01 +0000 Original-Received: (at 61960) by debbugs.gnu.org; 2 Jul 2023 05:51:56 +0000 Original-Received: from localhost ([127.0.0.1]:59030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFq04-0005d3-3F for submit@debbugs.gnu.org; Sun, 02 Jul 2023 01:51:56 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53302) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFpzy-0005cn-UO for 61960@debbugs.gnu.org; Sun, 02 Jul 2023 01:51:53 -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 1qFpzt-0000mA-Je; Sun, 02 Jul 2023 01:51:45 -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=7lyV12hSUcpbLqmspi0P/3Ewp4wLSKQzL6rke/iaxSo=; b=OSXoS/MuhvwI Z1MMJcZTN8p/EoqNanmPkHPosz6nL7/gKo7/Vu5LYGE2Au9Bkm1bZwGZkDkcwvjD4+42Tlnh5/lBl wfYHa5RO6odPMPSBwBr+CsFQ8/Ab6v/BkbSiK/jq5Zy/Ewelj9Vo7UinOQ0FE5x+M7EFjz297LoMg vOviu2NfsvuLOpR+Q6eLB+wyNLhCGpg1ljarrRDAc0kGuCDBSr5Jk18to/+WZwuiFPVzt0QkrLBOl fWpLPsIhzanF7FNqW34WHUrR1YdZoTdxfctbDYg/OBStsrQ5/x7HIocwvWJwLn7SxcB85DhZrFiFC ElF2O4dayucR8Z9KYHoBHA==; 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 1qFpzt-0004vS-13; Sun, 02 Jul 2023 01:51:45 -0400 In-Reply-To: <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> (message from Konstantin Kharlamov on Sun, 02 Jul 2023 04:50:26 +0300) 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:264444 Archived-At: > From: Konstantin Kharlamov > Date: Sun, 02 Jul 2023 04:50:26 +0300 > > I've found a diff that fixes the build, but whether it's okay is worth discussion: > > diff --git a/src/gmalloc.c b/src/gmalloc.c > index e655d69f660..f49bb01e08b 100644 > --- a/src/gmalloc.c > +++ b/src/gmalloc.c > @@ -1704,7 +1704,7 @@ allocated_via_gmalloc (void *ptr) > return false; > size_t block = BLOCK (ptr); > size_t blockmax = _heaplimit - 1; > - return block <= blockmax && _heapinfo[block].busy.type != 0; > + return block <= blockmax; > } > > /* See the comments near the beginning of this file for explanations > > Here's what happens: Emacs uses internal stack-based allocator (apparently allocating > with sbrk(), but I'm not sure) along with the system allocator. Whenever a memory is > allocated from the internal allocator, you can't call `free()` on it. > > When Emacs wants to free memory, it calls `hybrid_free_1()`, which internally > determines whether the `ptr` passed belongs to system heap or to Emacs > stack. Determining in turn is done by `allocated_via_gmalloc()`. > > Emacs also keeps the lowest and highest boundary of this stack in variables > `_heapbase` and `_heaplimit` accordingly (except the latter is measured in > "blocks"). The code in diff `block <= blockmax` simply makes sure that the `ptr` > passed is within the stack-allocated memory, which implies it can't be deallocated > with `free()` > > There's a question though of the right-hand side that I remove, the > `_heapinfo[block].busy.type != 0;`. Apparently the `type` should keep some memory > info, and apparently there's a bug somewhere that screws it up. It is a bug worth > fixing, although for some reason `rr replay` doesn't work for me with `temacs` > (probably a bug in rr), and without reverse-execution tracking that down would be > very hard. > > But I would argue that the right-hand side check has no value in this function, > because to determine the source of allocation it's enough to just check whether `ptr` > is in _heapbase .. _heaplimit range (barring the fact they're different units). Thanks, but how do you explain that this code works as-is when the BLOCK_ALIGN change is not used?