From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: GC and stack marking Date: Tue, 20 May 2014 22:43:39 +0300 Message-ID: <83tx8knslw.fsf@gnu.org> References: <83a9add91p.fsf@gnu.org> <8338g4bd7m.fsf@gnu.org> <537BA92D.50204@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1400615039 32512 80.91.229.3 (20 May 2014 19:43:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 May 2014 19:43:59 +0000 (UTC) Cc: fabrice.popineau@gmail.com, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 20 21:43:49 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 1Wmpwz-0000ri-5r for ged-emacs-devel@m.gmane.org; Tue, 20 May 2014 21:43:49 +0200 Original-Received: from localhost ([::1]:55158 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wmpwy-0000ki-Qp for ged-emacs-devel@m.gmane.org; Tue, 20 May 2014 15:43:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wmpwq-0000kN-G9 for emacs-devel@gnu.org; Tue, 20 May 2014 15:43:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wmpwk-00020K-UP for emacs-devel@gnu.org; Tue, 20 May 2014 15:43:40 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:55572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wmpwk-000208-8L for emacs-devel@gnu.org; Tue, 20 May 2014 15:43:34 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N5W009000UDW800@mtaout27.012.net.il> for emacs-devel@gnu.org; Tue, 20 May 2014 22:40:16 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N5W00AXO1B3AM10@mtaout27.012.net.il>; Tue, 20 May 2014 22:40:16 +0300 (IDT) In-reply-to: <537BA92D.50204@dancol.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 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:171967 Archived-At: > Date: Tue, 20 May 2014 12:12:45 -0700 > From: Daniel Colascione > CC: fabrice.popineau@gmail.com, emacs-devel@gnu.org > > >> But it shouldn't cause any trouble (other than extra memory use). > > > > It does, due to all kinds of subtleties. The result is that the > > large_vectors linked list gets dumped with a pointer to a non-existent > > memory, and the dumped Emacs then crashes on the first GC when it > > tries to traverse that linked list. > > Can you elaborate on how that happens? This behavior sounds like a plain > GC bug. It's not a bug in GC. The memory management scheme that Fabrice wrote does not dump the heap (because doing that is problematic on Windows, and requires addition of a separate section to the executable, which then precludes its stripping, and has also other complexities). Instead, temacs uses a private fixed-address heap that is located in a static array, and whose memory is allocated by a replacement malloc function. So any address that points to memory allocated not in that array, but in the real heap provided by malloc from libc, cannot be safely dumped, because in the dumped Emacs it will point to some random location. Now, the large_vectors list is a linked list chained via the next pointer. If one of these next pointers points to a memory on the heap, following it in the dumped Emacs will surely crash. There's no way GC can work around that, when it traverses that linked list.