From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#42832: 28.0.50; "Bus error" when compiling Emacs now on Debian bullseye Date: Fri, 14 Aug 2020 14:24:48 +0000 Message-ID: References: <878sejlrfd.fsf@gnus.org> <87zh6zk9m2.fsf@gnus.org> <87tux7k97r.fsf@gnus.org> <83364rog0t.fsf@gnu.org> <87lfijk7y4.fsf@gnus.org> <87h7t7k6ke.fsf@gnus.org> <87d03vk6am.fsf@gnus.org> <50a72536-c274-9a69-2b03-d82154f3e20c@cs.ucla.edu> <878sejk2wo.fsf@gnus.org> <874kp7jzsf.fsf@gnus.org> <87lfiig8hz.fsf@gnus.org> <87h7t6g8bt.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6382"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 42832@debbugs.gnu.org, Paul Eggert To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Aug 14 16:26:10 2020 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 1k6aeo-0001Ym-BA for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Aug 2020 16:26:10 +0200 Original-Received: from localhost ([::1]:37062 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k6aen-0003jU-E6 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Aug 2020 10:26:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36316) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k6aeg-0003jJ-6k for bug-gnu-emacs@gnu.org; Fri, 14 Aug 2020 10:26:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41860) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1k6aef-0008ST-UF for bug-gnu-emacs@gnu.org; Fri, 14 Aug 2020 10:26:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1k6aef-0000sG-Qz for bug-gnu-emacs@gnu.org; Fri, 14 Aug 2020 10:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Aug 2020 14:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42832 X-GNU-PR-Package: emacs Original-Received: via spool by 42832-submit@debbugs.gnu.org id=B42832.15974151313321 (code B ref 42832); Fri, 14 Aug 2020 14:26:01 +0000 Original-Received: (at 42832) by debbugs.gnu.org; 14 Aug 2020 14:25:31 +0000 Original-Received: from localhost ([127.0.0.1]:53406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k6aeB-0000rV-Jg for submit@debbugs.gnu.org; Fri, 14 Aug 2020 10:25:31 -0400 Original-Received: from mail-ot1-f45.google.com ([209.85.210.45]:43307) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k6aeA-0000rJ-2W for 42832@debbugs.gnu.org; Fri, 14 Aug 2020 10:25:30 -0400 Original-Received: by mail-ot1-f45.google.com with SMTP id r21so7672560ota.10 for <42832@debbugs.gnu.org>; Fri, 14 Aug 2020 07:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4pqR6QXSij0FxpPntYrFxDmmXuJ5u9KEbWLmqKNIMm8=; b=iA0MGGTAUtb1XCXDEMSxN+qkUflvOmuCuCxfWfLX2SMdoDg6NV/P0sbdjVFBA5sGnv stHTCn6mujDVlwEp6GXGWX+5TIEC1YnHFOBDXpfVap3d1QHsZsaGvMbDLHt8r7ux6cNZ JAfYMYJ0BfzBrEZgPhO+H6l2Yorlds6/TtIefFHfuez4xG0gd5kFkMXsr8ySwqZNI8XR bc5DMomeCDvA/LbztZbsxuyGnQsRYY76rq4c+lCfHyNlquZeaFpQl74jJdqIM9ANZqqW fUNsl79qDs+9GUIWbhrccrJYapSWO45/UzK2P8hvEl6iHx1tAeMnhSj4kgeIOsDjU8CM 8alA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4pqR6QXSij0FxpPntYrFxDmmXuJ5u9KEbWLmqKNIMm8=; b=XORnmqBUuvcomvvM5MYhJp3nPG3b+cO1AQSYv/2EzDgN/vspZcvH2IX2ZD8h308t2E mf/wdhjpLJcznJTT8FEMa1gT7rQqQf6P4k1G9rnbt6Dk/qKwnp2quDpBoKehi71huiSC K87sYYMcrg9zBUNHB1+ZPqDWuFbJHfxVlTmrxLQDwZN24Xx3eAm3XLAuXMUSLTQwpFj0 FEuFLs6ReeuqBiqL3xNbwfuqxYwzz8THFwsSrqquw7I517n/PqYaBVziiX5Z8O331XGy qEG/Og5j0tklmBD5bV8Jw3oeMbTpmaJ2erJ9P1K74W6qex9YWq43ur8/1B8drE84svgo lJ1g== X-Gm-Message-State: AOAM530WrrIGyHIHWmZh0ImZB0QhabRWewsP5YnpesBE1GmFUB4WlLJi ojswZVJttL6VRS4QozLzh4zOOZo4QQ6P4miAG7g= X-Google-Smtp-Source: ABdhPJzBaNhFfl9If1soZc/vRl7XEmZIJGyEvsLysnw5pTfKmq/IbYM8xVBoZ053amc23Q7htT5xjksrgB/AZMoGPbY= X-Received: by 2002:a05:6830:13d1:: with SMTP id e17mr2140711otq.292.1597415124414; Fri, 14 Aug 2020 07:25:24 -0700 (PDT) In-Reply-To: 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" Xref: news.gmane.io gmane.emacs.bugs:185114 Archived-At: On Thu, Aug 13, 2020 at 2:08 PM Pip Cet wrote: > All that sounds to me like we ought to dig down into the core file and > figure out what happened, since the issue is likely to remain present > otherwise and it seems somewhat difficult to track down and reproduce. I have a theory, and it sounds like a somewhat silly bug. - there's a hash table h in the dumper image - h->hash points to dynamically allocated storage (as it always does after my patch) - the last reference to the hash table dies - garbage_collect is called and collects h->hash - h->hash's storage is reallocated for a different vector with a different start position - a word (re)appears on the stack which looks like it's a pointer to h (it isn't, actually) - garbage_collect is called and calls mark_maybe_pointer(h) - h is recognized as a pdumper object - h->hash is marked - we're now marking a word in the middle of the new vector that occupies the space that h->hash used to occupy - in our case, this word is 0xc000000018000005, which is interpreted as a tagged pointer, dereferencing of which leads to SIGBUS Is there something which I'm missing which would prevent this scenario? If no, any ideas on how to fix it? The obvious fix would be to always mark all pdumped objects, but that has a performance cost. Less obvious would be clearing the memory in the pdumper image that belongs to an object that's being "freed", or keeping track of which pdumper objects are still valid after GC...