From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.bugs Subject: bug#61960: 30.0.50; Unexec build reliably crashes during loadup Date: Fri, 21 Jul 2023 19:09:04 +0300 Message-ID: <26a72dd4ef44849cbf2ed99f61199779e411136f.camel@yandex.ru> References: <62049aa9ffcf9f39fd423fb87cd8dc8e0b77f9b8.camel@yandex.ru> <63f3de6f0cc0d015d2dcbcdd6adc95482dc0c6ad.camel@yandex.ru> <835y72q2r1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23109"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.48.4 Cc: 61960@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 21 18:09:30 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 1qMsh4-0005jZ-1s for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 21 Jul 2023 18:09:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qMsgl-0004CX-Ix; Fri, 21 Jul 2023 12:09:07 -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 1qMsgg-00049N-9p for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2023 12:09:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qMsgg-00079n-1e for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2023 12:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qMsgf-0006LG-PI for bug-gnu-emacs@gnu.org; Fri, 21 Jul 2023 12:09:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Jul 2023 16:09: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.168995573724367 (code B ref 61960); Fri, 21 Jul 2023 16:09:01 +0000 Original-Received: (at 61960) by debbugs.gnu.org; 21 Jul 2023 16:08:57 +0000 Original-Received: from localhost ([127.0.0.1]:34647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMsga-0006Kw-Ub for submit@debbugs.gnu.org; Fri, 21 Jul 2023 12:08:57 -0400 Original-Received: from forward500c.mail.yandex.net ([2a02:6b8:c03:500:1:45:d181:d500]:45956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMsgY-0006Kk-Ls for 61960@debbugs.gnu.org; Fri, 21 Jul 2023 12:08:55 -0400 Original-Received: from mail-nwsmtp-smtp-production-main-87.sas.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-87.sas.yp-c.yandex.net [IPv6:2a02:6b8:c08:9396:0:640:dd2a:0]) by forward500c.mail.yandex.net (Yandex) with ESMTP id A6AEB5ECB8; Fri, 21 Jul 2023 19:08:48 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-87.sas.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id j8mTlA1DXqM0-315HdIHE; Fri, 21 Jul 2023 19:08:48 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1689955728; bh=lO+FrJVxqZgkhdfutW9YIsWnRdB7qkBfdjn5Ke/ptno=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=RXEyPfeI5rov8EbJ4gpA6fia7JdwyCRefqDA1Sin4jnYFylCp+HDUW5qWpFx6n8AQ 2TsYTQN7ufWSshvtk7ctMA5lS4MTdTMSnhwoY+n92MWjw7KxPq7Bp5km1SY4RNTsh2 tblwDwemmgu11+K7BpYGC0QdbThBnbcb7Bv1rnAA= Authentication-Results: mail-nwsmtp-smtp-production-main-87.sas.yp-c.yandex.net; dkim=pass header.i=@yandex.ru 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:265738 Archived-At: Okay, so I've spent today a lot of time debugging this problem, and out of interesting things I found so far the following: 1. Problem seems like some discrepancy between _heapinfo and an abase whose index points at _heapinfo 2. Given two Emacs executions, one which buggy and one isn't, I found that "good execution" returns from `aligned_alloc` the same result it gotten from `_malloc_internal_nolock`, whereas in "bad execution" it's different. The reason for this is that inside `aligned_alloc()` "good execution" *never* goes into `if (adj !=3D 0)` condition. The function has 3 places where `malloc` is called (which is not actually a malloc() but instead a wrapper `gmalloc` eventually calling into `_malloc_internal_nolock()`), one of which is inside the mentioned condition. The latter one changes `malloc` result, while 2 others do not. In the lieu of that it is possible that this conditional branch simply was never tested. I decided to check how it works in a usual Emacs build, and I found out that it doesn't even have `gmalloc.c` source compiled in =F0=9F=A4=B7=E2=80=8D=E2=99=82=EF=B8=8F ----------------------- That makes me wonder if keeping this whole customized allocation engine even makes sense. It is not used in the actual Emacs, only in `temacs` =E2=80=94 but why? Is it to make `temacs` faster? I would imagine in the "compilation usecase" where `temacs` is used, shaving off a few seconds is not worth that complexity (not to mention I am not sure how well this code may compete with specialized allocator projects like "jemalloc", which also do allocation caching). This code is incomprehensible. It does funny stuff like redefining system functions, like `malloc` to its wrappers, so even just reading it is hard. And I've spent hours watching simultaneously two `temacs` executions, "bad" and "good" one, recorded with `rr record`, using reverse-execution and watchpoints and still not sure how close I am to solving the case.=20 So, I would be glad to hear what people think about the purpose of this gmalloc being in the project.