From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: GC bug investigation Date: Sun, 23 Mar 2014 10:57:34 -0400 Message-ID: References: <532CEDEF.90707@dancol.org> <532E3FB9.6040501@dancol.org> Reply-To: rms@gnu.org NNTP-Posting-Host: plane.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1395586648 29139 80.91.229.3 (23 Mar 2014 14:57:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Mar 2014 14:57:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 23 15:57:39 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 1WRjqF-0006D8-BI for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2014 15:57:39 +0100 Original-Received: from localhost ([::1]:60497 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRjqF-0002mV-1y for ged-emacs-devel@m.gmane.org; Sun, 23 Mar 2014 10:57:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRjqB-0002mO-FJ for emacs-devel@gnu.org; Sun, 23 Mar 2014 10:57:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WRjqA-0004ej-K8 for emacs-devel@gnu.org; Sun, 23 Mar 2014 10:57:35 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WRjqA-0004ee-Hs for emacs-devel@gnu.org; Sun, 23 Mar 2014 10:57:34 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1WRjqA-0006Tk-4L; Sun, 23 Mar 2014 10:57:34 -0400 In-reply-to: <532E3FB9.6040501@dancol.org> (message from Daniel Colascione on Sat, 22 Mar 2014 18:58:17 -0700) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:170866 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Details of the objects on the path might be useful. I don't understand "on the path". mark_object(A) mark_vectorlike(B) mark_object(B) mark_object(clear-transient-map) Right. B here is clear-transient-map's function cell, right? You're saying you saw that it's a pseudovector that safe_debug_print reports as INVALID_LISP_OBJECT, probably because live_vector_p returns 0. Yes. That we're reaching B at all indicates that it shouldn't be dead. I guess so. This is the mysterious part. B must have been made dead *before* being assigned to clear-transient-map's function cell. Looking at the bytecode in set-transient-map, though, I don't see how that's possible. I don't think that's what happened. If it were that, we would see crashes when that code tries to _use_ the value legitimately. clear-transient-map isn't dead either, It has not been freed, it seems, but it may be garbage. It is being marked through a spurious pointer randomly hanging around in a stack slot for something else. We don't know that there is any real pointer to it. I don't think that writing code that aborts or breaks when a particular vector is freed will be very helpful; we'll hit that code in normal operation too. Instead, it'll probably be more useful to print a backtrace (using emacs_backtrace) each time we see that vectorlike freed, then look at the last backtrace before the GC crash. Maybe you are right. Can you try running with -DGC_CHECK_MARKED_OBJECTS=1 in your CFLAGS? I can, but it would be a big pain. It takes many hours to recompile Emacs on this machine. What would it tell us? It would confirm that the vectorlike was freed, perhaps, but do we doubt that? If that hassle is likely to solve the problem, I'll do it, but I'd rather not go to that hassle just to confirm what we know. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use Ekiga or an ordinary phone call.