From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.emacs.devel Subject: Re: Dumper problems and a possible solutions Date: Wed, 25 Jun 2014 17:24:21 -0400 Message-ID: <20140625212421.GD179@brightrain.aerifal.cx> References: <20140624171955.GS179@brightrain.aerifal.cx> <53AB0EF8.4090608@yandex.ru> <831tucrguf.fsf@gnu.org> <20140625183241.GW179@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1403731487 23016 80.91.229.3 (25 Jun 2014 21:24:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 21:24:47 +0000 (UTC) Cc: Eli Zaretskii , Dmitry Antipov , emacs-devel@gnu.org To: Samuel Bronson Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 25 23:24:40 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WzugK-0000dl-8o for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 23:24:40 +0200 Original-Received: from localhost ([::1]:41079 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzugJ-0008AR-SK for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 17:24:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35954) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzugD-0008AG-5j for emacs-devel@gnu.org; Wed, 25 Jun 2014 17:24:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wzug8-0004OA-RG for emacs-devel@gnu.org; Wed, 25 Jun 2014 17:24:33 -0400 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:44445 helo=brightrain.aerifal.cx) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzug4-0004MG-4i; Wed, 25 Jun 2014 17:24:24 -0400 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1Wzug1-0005Hy-00; Wed, 25 Jun 2014 21:24:21 +0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 216.12.86.13 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172730 Archived-At: On Wed, Jun 25, 2014 at 04:53:58PM -0400, Samuel Bronson wrote: > On 6/25/14, Rich Felker wrote: > > > In musl's malloc, we use brk if it's available (note: with PIE, most > > kernels give you almost no available brk space due to the way the > > mappings are laid out) [...] > > Yeah, that tiny gap has bitten in other ways, too: > > talks about a stack overflow with the same cause; I really think the > kernel should stop doing that. Agreed. But it was a big enough issue (basically a show-stopper for using PIE) that I just added a simple way to use mmap without having to care about discontiguity because the waste is asymptotically zero. > > Also, musl does not provide a working sbrk at all, since synchronizing > > with an application's use of sbrk would introduce performance costs > > into all correct applications that don't poke at the brk. > > Looking at the manpage, I can't really follow how having sbrk() would > involve a slowdown in everything? Do you mean that musl's malloc gets > a speed bonus out of assuming it's the sole user of brk()/sbrk(), and > thus the whole region from the initial brk()point to the current > brk()point is belongs to it? Yes, basically. malloc simply assumes the brk is where it last left it, rather than querying it again, which would double the syscall overhead. This could be avoided via a cooperating lock between sbrk and malloc, but basically after sbrk touches the brk, malloc could not safely use it anymore; if it did, the application might later clobber malloc's heap. brk/sbrk are documented as not being usable if malloc is used (see http://pubs.opengroup.org/onlinepubs/7908799/xsh/brk.html) and they were later removed from the standards because that essentially makes it impossible to use them at all. There's an ongoing discussion on whether it's desirable to provide an emulated sbrk for legacy applications (note: these applications would not work with real sbrk anyway if compiled as PIE!) but since there are basically no users of brk/sbrk left except malloc implementations, nobody has really cared much one way or the other whether it gets added. > (Yeah, all (potentially) 125 MiB - > stacksize of it!) I don't follow. brk has nothing to do with the stack, and in practice it can obtain nearly the full 3GB (for 32-bit) of available virtual address space in non-PIE programs. Anyway, discussion of musl's malloc implementation is largely off-topic to this discussion except insomuch as it reflects the diversity of implementation possibilities that it would be nice for emacs to support without ugly hacks. I'd rather this thread not be "please change emacs because __________ in musl" but rather "let's address a long-standing portability issue in emacs in such a way that it won't come up again, and possibly gives other benefits like support for PIE and fixing ugly corner-cases that are going to arise now that modern emacs is linking so many libraries". Rich