From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.devel Subject: Re: Help please! To track down GC trying to free an already freed object. Date: Tue, 2 Apr 2019 14:03:52 -0700 Message-ID: <5adec1c4c1287f6a7b7eb63b832cc2cb.squirrel@dancol.org> References: <20190402112537.GA6212@ACM> <835zrwfc21.fsf@gnu.org> <20190402204653.GC25792@ACM> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="82104"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Eli Zaretskii , Daniel Colascione , emacs-devel@gnu.org To: "Alan Mackenzie" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 02 23:04:29 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hBQa2-000LB1-RF for ged-emacs-devel@m.gmane.org; Tue, 02 Apr 2019 23:04:27 +0200 Original-Received: from localhost ([127.0.0.1]:46179 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBQa1-0007mD-MQ for ged-emacs-devel@m.gmane.org; Tue, 02 Apr 2019 17:04:25 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBQZr-0007ks-JB for emacs-devel@gnu.org; Tue, 02 Apr 2019 17:04:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBQZq-0007y7-Ix for emacs-devel@gnu.org; Tue, 02 Apr 2019 17:04:15 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:46886) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hBQZV-0007uK-TS; Tue, 02 Apr 2019 17:03:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=l+Hr4W69KGm0bli6dGjN/ucp3uMdnI6ZkbpqfgdJJFc=; b=aj2W989UG8BXGf3VUIeeokVrQukrbZrkNICas7k6azWuOusxYf0Ed74SYZBTRe775XWmUwSmLV+rbllpWP/8RADM03zGwvhoLRCsyD2IRaDpNosHbhyC8XBHlzHli+gP1WV6gqNMJ5c0hRM5bo/F8KGvNNfT6Uz+5FtvmQE2V4+MCB3l34QK1M8i4GsBorCU499S+Uj2Ps7ybIEZw+mh5ZtemRTlkw+oEjFODfB8UEKvqHklmi/13TnQoeCP//66KkJmO8UEnZ7BOLd/ezPvN6Y3Ax8LUwKkm+4tvvtPVZDZIoJ/sfLaby/ofAtTgl5fDy2XdRGSJiZIWutccK6QrA==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBQZU-0006hq-GW; Tue, 02 Apr 2019 14:03:52 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Tue, 2 Apr 2019 14:03:52 -0700 In-Reply-To: <20190402204653.GC25792@ACM> X-Priority: 3 (Normal) Importance: Normal X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:234904 Archived-At: > Hello, Eli. > > On Tue, Apr 02, 2019 at 22:21:26 +0300, Eli Zaretskii wrote: >> > Date: Tue, 2 Apr 2019 12:09:59 -0700 >> > From: "Daniel Colascione" >> > Cc: emacs-devel@gnu.org >> > >> > rr is incredibly helpful for debugging this sort of problem. See >> > https://rr-project.org/. You can record an rr session containing the >> > crash, replay it, get to the crash, and then reverse-next, >> reverse-finish, >> > and reverse-continue your way through the GC, running it in reverse >> until >> > you find whatever it is that made mark_object on the dead object >> happen. > >> GDB supports reverse execution as well, on some platforms. > > On my GNU/Linux system, I tried to run 'reverse-next', and got the error > message: > > Target multi-thread does not support this command. > > . :-( I suppose I could reconfigure without multi threading, but then > the bug (which is reproducible) probably wouldn't happen in the same > place. I don't think I've ever gotten pure-GDB reverse execution to work correctly. rr Just Works for me in every instance I've tried it.