From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: Intermittent unexec failures on Linux >= 2.6.25 Date: Tue, 21 Oct 2008 08:32:49 +0200 Message-ID: <48FD7791.5070806@swipnet.se> References: <18623.4028.181298.302150@a1ihome1.kph.uni-mainz.de> <20081020192033.3252b4bf@terra.solaris> <87ej2bi20r.fsf@cyd.mit.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1224570821 27982 80.91.229.12 (21 Oct 2008 06:33:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Oct 2008 06:33:41 +0000 (UTC) Cc: Christian Faulhammer , emacs-devel@gnu.org, emacs@gentoo.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 21 08:34: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 1KsAp9-0005hC-VW for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2008 08:34:36 +0200 Original-Received: from localhost ([127.0.0.1]:60666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsAo4-0002Np-Kd for ged-emacs-devel@m.gmane.org; Tue, 21 Oct 2008 02:33:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KsAnz-0002Lp-MK for emacs-devel@gnu.org; Tue, 21 Oct 2008 02:33:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KsAnx-0002Ld-3v for emacs-devel@gnu.org; Tue, 21 Oct 2008 02:33:22 -0400 Original-Received: from [199.232.76.173] (port=42125 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KsAnw-0002La-UV for emacs-devel@gnu.org; Tue, 21 Oct 2008 02:33:20 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:64023) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KsAnw-0005SR-Ph for emacs-devel@gnu.org; Tue, 21 Oct 2008 02:33:20 -0400 Original-Received: from proxy1.bredband.net ([195.54.101.71]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KsAnu-0000Sq-N1 for emacs-devel@gnu.org; Tue, 21 Oct 2008 02:33:18 -0400 Original-Received: from ironport2.bredband.com (195.54.101.122) by proxy1.bredband.net (7.3.127) id 48DC49FD0075A256 for emacs-devel@gnu.org; Tue, 21 Oct 2008 08:33:16 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8vAAMU/UhV4S2yPGdsb2JhbACBcpFzAQEBATWvbINQ Original-Received: from c-b22de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO husetbladh.homeip.net) ([85.225.45.178]) by ironport2.bredband.com with ESMTP; 21 Oct 2008 08:33:15 +0200 User-Agent: Thunderbird 2.0.0.17 (X11/20080925) In-Reply-To: <87ej2bi20r.fsf@cyd.mit.edu> X-detected-kernel: by mx20.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:104724 Archived-At: I got it from the kernel source at the time. I see now that there is no lower limit on the heap gap produced by randomization. I guess we must exec every time to be sure. I think it is only heap randomization that unexec has problems with. Other address randomizations are ok. But we will unconditionally turn off all of them when we exec and dump. I have checked in a fix. Jan D. Chong Yidong skrev: > 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.)