From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nikolay Kudryavtsev Newsgroups: gmane.emacs.devel Subject: Re: Unexec dumping results in "Segmentation fault" on Windows Msys2 Date: Thu, 15 Apr 2021 01:11:53 +0300 Message-ID: References: <83im52ed8b.fsf@gnu.org> <989be2e0-a090-309b-58cb-8064c6bd5aee@gmail.com> <83y2dycmgr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5243"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 15 00:12:46 2021 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 1lWnkb-0001FW-T5 for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Apr 2021 00:12:45 +0200 Original-Received: from localhost ([::1]:52716 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lWnka-0003gd-Tc for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Apr 2021 18:12:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58110) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lWnjs-0003F2-Gs for emacs-devel@gnu.org; Wed, 14 Apr 2021 18:12:00 -0400 Original-Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]:42855) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lWnjq-0005NQ-Db; Wed, 14 Apr 2021 18:12:00 -0400 Original-Received: by mail-lj1-x234.google.com with SMTP id l22so17565825ljc.9; Wed, 14 Apr 2021 15:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ono2Wd0nL1jrMTocYy4bLZf1ua0Jgbgzw8EgEOjzJaY=; b=Mjng/Zqnmmxy4OhTtZyxbXeSuWDM/HVsJUYNc3Z8osoVuqEDw1a9eSP7OCbAFXNQEa FFLnNBxYaRMfINDXBPiNd5nq+18i83dG7JTo+uXIu+eXSbnvcfqFfJ4nyg0URQZp97TD Ham8m4Oewq4y5mvYkLi9lj1mnIzjyoGfBMfHA5HU59FIZPnFaaFoVukSX6fqzpjGiTdO DM4kYhDO3qmCnPs4l9SBfvZTQIhxtKo2SsCCy+Yiu/iRE7wws1XhOwItpg++ZA385sPt wrNu0KNW70CENWDCiX73NjB3aD9R/LMY0wAJsGbDknO0UdLX6DTSbZZtOh2rTSUQ69LP ST4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ono2Wd0nL1jrMTocYy4bLZf1ua0Jgbgzw8EgEOjzJaY=; b=RTju9IJhNwWfkOy9YIBecxzh1TDRI9e1VBdP8+A4h9f09aj9vBkHP2bViEVNJiWyxV gs6lc69Wti7gLvyeCyOVlYebitk6IGqiszzR5k5CULf0lzwtTWEvsf8HLJPAkBTTfWUv fsje2UivDSMhLw6rZF8m2M8kVfBtCZxWB0Afq3Ozrb5kwabw/t6C7/T0GLqZEDGzPrDu BPpV7Qjc7MIosVbXXgu6uJFLvl5dP8Mu5Bq4BdkHDevzIWOOUo21uks4HNTbvLHvqTSt und9+yU2U+n84hcTjxJdbWUtmUOGDcoozpREzyeBqvJieSYl1Dnu/hMR5x9EN8qS6nK2 t2Kg== X-Gm-Message-State: AOAM530eiqThh0hIdEkXrbiumX7Nm8b71NCcDTm6AcMiCu4qiDrti0Fi uM/cPZ9JxDPG4sfSpabYCEAwjNpvnAs= X-Google-Smtp-Source: ABdhPJwlhLMjpVulpBUTOjNmvtkHltdqci5TKh3b1sSBT+ihQcXftumbjTkwtwEKIbgcLnZvvuULBQ== X-Received: by 2002:a2e:8e28:: with SMTP id r8mr93385ljk.156.1618438315257; Wed, 14 Apr 2021 15:11:55 -0700 (PDT) Original-Received: from ?IPv6:2a02:2168:b115:9d00:6b58:8bba:62e0:acd5? ([2a02:2168:b115:9d00:6b58:8bba:62e0:acd5]) by smtp.gmail.com with ESMTPSA id t9sm272317lfl.34.2021.04.14.15.11.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Apr 2021 15:11:54 -0700 (PDT) X-Google-Original-From: Nikolay Kudryavtsev In-Reply-To: <83y2dycmgr.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::234; envelope-from=nikolay.kudryavtsev@gmail.com; helo=mail-lj1-x234.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, NICE_REPLY_A=-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.23 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" Xref: news.gmane.io gmane.emacs.devel:268069 Archived-At: Here's what I was able to gather in regards to this issue. Whenever I'm trying to build master I get: dumped_data_commit: memory exhausted. Enlarge dumped_data[]! Due to this I have to set DUMPED_HEAP_SIZE (24*1024*1024). Just mentioning this for completeness sake, that's not the issue here. Segfaults are triggered by msys2 binutils version 2.36. If we try to debug the segfault with GDB we get this: Thread 1 received signal SIGSEGV, Segmentation fault. 0x00007ff7c7514862 in main (argc=9, argv=0x1f815ad1860)     at D:/Emacs/source/repo/src/emacs.c:960 960       stack_bottom = (char *) &stack_bottom_variable; It seems like the initial bootstrap-emacs.exe is so broken that it fails at even the simplest things. The question I keep asking myself is, if we assume that it's our build environment that has some problem, why is unexec the only place that is harmed by it? Would it be possible to come up with some isolated test case that would demonstrate the problem? Then maybe it can be submitted to msys2 or mingw64 developers. Now, lets downgrade binutils to version 2.35(or older), you can do that by grabbing the archive from here( https://repo.msys2.org/mingw/x86_64/ ) and then calling "pacman -U  mingw-w64-x86_64-binutils-2.35.1-3-any.pkg.tar.zst" on it. Emacs versions 27.2, 27.1, 26.3 and older would compile fine. But the master still won't. Instead of a segfault we get a more helpful Emacs crash. If we attach gdb to it, here's what we get: #10 0x00007ff911ef0a9e in ntdll!KiUserExceptionDispatcher ()    from /c/WINDOWS/SYSTEM32/ntdll.dll #11 0x00007ff9103c43d7 in msvcrt!memmove () from /c/WINDOWS/System32/msvcrt.dll #12 0x0000000400191e25 in insert_1_both (     string=0x4506840 "(fn FILENAME)\377\377\377", nchars=13, nbytes=13,     inherit=false, prepare=true, before_markers=false)     at D:/Emacs/source/repo/src/insdel.c:915 #13 0x000000040024f689 in Fprin1_to_string (object=..., noescape=...)     at D:/Emacs/source/repo/src/print.c:685 #14 0x000000040020be9a in styled_format (nargs=2, args=0xbf0720, message=false)     at D:/Emacs/source/repo/src/editfns.c:3322 #15 0x000000040020b69f in Fformat (nargs=2, args=0xbf0720)     at D:/Emacs/source/repo/src/editfns.c:3059 #16 0x000000040021b946 in eval_sub (form=...)     at D:/Emacs/source/repo/src/eval.c:2363 #17 0x000000040021dbd0 in apply_lambda (fun=..., args=..., count=228)     at D:/Emacs/source/repo/src/eval.c:3056 Again, memory related. Since we know that unexec works in emacs26 and emacs27 branches, I went for another row of bisecting and traced the offending commit to cddf85d256. Now this is interesting in that if unexec triggers a crash here, is there a way to get this to crash Emacs during the normal usage? Also, I have an old msys2 backup from 2017 that I've used for testing and I'm getting the same kind of exceptions with it, so I don't think we can write this master branch issue off on the build environment.