From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Intermittent unexec failures on Linux >= 2.6.25 Date: Mon, 20 Oct 2008 13:56:20 -0400 Message-ID: <87ej2bi20r.fsf@cyd.mit.edu> References: <18623.4028.181298.302150@a1ihome1.kph.uni-mainz.de> <20081020192033.3252b4bf@terra.solaris> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1224539859 29535 80.91.229.12 (20 Oct 2008 21:57:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Oct 2008 21:57:39 +0000 (UTC) Cc: Christian Faulhammer , emacs-devel@gnu.org, emacs@gentoo.org To: Jan =?utf-8?Q?Dj=C3=A4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 20 23:58:39 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Krz0X-0004n6-Oa for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2008 19:57:34 +0200 Original-Received: from localhost ([127.0.0.1]:39388 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KryzR-0001zE-KW for ged-emacs-devel@m.gmane.org; Mon, 20 Oct 2008 13:56:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KryzO-0001z7-5D for emacs-devel@gnu.org; Mon, 20 Oct 2008 13:56:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KryzM-0001yv-J1 for emacs-devel@gnu.org; Mon, 20 Oct 2008 13:56:21 -0400 Original-Received: from [199.232.76.173] (port=38620 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KryzM-0001yk-Ds for emacs-devel@gnu.org; Mon, 20 Oct 2008 13:56:20 -0400 Original-Received: from cyd.mit.edu ([18.115.2.24]:32903) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KryzM-0005E4-JV for emacs-devel@gnu.org; Mon, 20 Oct 2008 13:56:20 -0400 Original-Received: by cyd.mit.edu (Postfix, from userid 1000) id 0EBA057E0B3; Mon, 20 Oct 2008 13:56:21 -0400 (EDT) In-Reply-To: <20081020192033.3252b4bf@terra.solaris> (Christian Faulhammer's message of "Mon, 20 Oct 2008 19:20:33 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:104697 Archived-At: Hi Jan, >> Building of Emacs 22.2.92 (also 22.2) on Linux 2.6.25 (or later) >> sometimes fails with a segmentation fault in dump-emacs / unexec. >> >> This was reported by Jan Hrabe as Gentoo bug 236579, >> . >> >> I've investigated and found that indeed temacs fails in dump-emacs >> intermittently. For my test, I have run "make; rm src/emacs" 250 times >> in a loop, and in 3 cases a segmentation fault of temacs occured. >> >> The problem seems to be that heap_bss_diff is too large for unexec >> to succeed (due to kernel heap randomisation, see >> ). >> >> On the other hand, it is (in case of the 3 failures) not large enough >> to fulfill the condition (heap_bss_diff > MAX_HEAP_BSS_DIFF) which >> would trigger the correct behaviour, namely setting the personality >> and calling execve of itself. Do you remember the rationale for setting #define MAX_HEAP_BSS_DIFF (1024*1024) in emacs.c? This variable was introduced by you on 2004-10-20, and I'm not too familiar with this part of the code. >> In the 247 successful cases, heap_bss_diff first had a large value >> (up to about 32 MiB), and in the exec'd temacs its value was constant, >> namely 1887 bytes. >> >> The 3 failures had heap_bss_diff = 575327, 911199, and 268127, which >> are all smaller than MAX_HEAP_BSS_DIFF (1024*1024), so execvp was >> _not_ called. >> >> Where does that value of MAX_HEAP_BSS_DIFF = 1 MiB come from? Could it >> be decreased, or could temacs execve itself unconditionally on Linux? >> In my opinion, a failure rate of about 1 % is too high. >> >> (The problem doesn't exist for Linux 2.6.24, or if heap randomisation >> is turned off, i.e. with /proc/sys/kernel/randomize_va_space < 2.)