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 19:57:01 +0300 Message-ID: <8338g4bd7m.fsf@gnu.org> References: <83a9add91p.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1400605041 9528 80.91.229.3 (20 May 2014 16:57:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 May 2014 16:57:21 +0000 (UTC) Cc: fabrice.popineau@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 20 18:57:14 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 1WmnLg-0007Ec-BH for ged-emacs-devel@m.gmane.org; Tue, 20 May 2014 18:57:08 +0200 Original-Received: from localhost ([::1]:54584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmnLg-0005SM-2M for ged-emacs-devel@m.gmane.org; Tue, 20 May 2014 12:57:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmnLY-0005RK-VJ for emacs-devel@gnu.org; Tue, 20 May 2014 12:57:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WmnLT-0003kD-Qv for emacs-devel@gnu.org; Tue, 20 May 2014 12:57:00 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:61199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WmnLT-0003ji-Jq for emacs-devel@gnu.org; Tue, 20 May 2014 12:56:55 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0N5V00900TC8I000@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Tue, 20 May 2014 19:56:54 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N5V009G7TQTHR20@a-mtaout21.012.net.il>; Tue, 20 May 2014 19:56:54 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:171960 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org, Fabrice Popineau > Date: Tue, 20 May 2014 09:44:05 -0400 > > > The short version of the question is: is it possible that a Lisp > > object which is no longer referenced by anything won't be GC'ed > > because it is marked by mark_stack due to some kind of coincidence? > > Yes, of course, it's what makes a conservative marking conservative. I have nothing against conservative, but this failure to GC is too spectacular to ignore. > > So the huge hash-table gets dumped into the emacs executable, and > > That's bad luck, indeed. > > > causes all kinds of trouble in the dumped Emacs. > > 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. > > If this can legitimately happen, then how can we make sure this > > hash-table indeed gets GC'd before we dump Emacs? > > First we should make sure that even if this table is not GC'd, Emacs > behaves correctly. Fabrice might have found a work-around, so there is hope. I found a way to kludge around it, but my solution is more fragile. Otherwise, we probably have a bug that can appear in > other situations. > > - find where the spurious "reference" is coming from and add code to set > this reference to some other value I think this is hopeless: I see this problem on a single system; two others don't have it. It's just some semi-random garbage somehwre on the stack.