From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Help please! To track down GC trying to free an already freed object. Date: Tue, 2 Apr 2019 20:24:12 +0000 Message-ID: <20190402202412.GA25792@ACM> References: <20190402112537.GA6212@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="173178"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 02 22:25:07 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 1hBPxx-000ivR-Vm for ged-emacs-devel@m.gmane.org; Tue, 02 Apr 2019 22:25:06 +0200 Original-Received: from localhost ([127.0.0.1]:34816 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBPxw-0002qg-QS for ged-emacs-devel@m.gmane.org; Tue, 02 Apr 2019 16:25:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34274) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBPxI-0002qQ-OH for emacs-devel@gnu.org; Tue, 02 Apr 2019 16:24:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBPxH-0002fO-3A for emacs-devel@gnu.org; Tue, 02 Apr 2019 16:24:24 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:52173 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hBPxG-0002aZ-OB for emacs-devel@gnu.org; Tue, 02 Apr 2019 16:24:23 -0400 Original-Received: (qmail 2996 invoked by uid 3782); 2 Apr 2019 20:24:13 -0000 Original-Received: from acm.muc.de (p4FE15EFB.dip0.t-ipconnect.de [79.225.94.251]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 02 Apr 2019 22:24:12 +0200 Original-Received: (qmail 25881 invoked by uid 1000); 2 Apr 2019 20:24:12 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:234898 Archived-At: Hello, Daniel. On Tue, Apr 02, 2019 at 12:09:59 -0700, Daniel Colascione wrote: > > Hello, Emacs. > > I get this problem after a recent merge of master into > > /scratch/accurate-warning-pos (my branch where I'm trying to implement > > correct source positions in the byte compiler's warning messages). This > > was a large merge, including bringing in the portable dumper. > > Emacs aborts at mark_object L+179 (in alloc.c), because a pseudovector > > being freed already has type PVEC_FREE, i.e. has been freed already. > > This object is a "symbol with position", a type of pseudovector which > > doesn't yet exist outside of this scratch branch. > Out of curiosity, why do we need a new C-level type here? It's to help solve a bug in the byte compiler, which up until recently was intractable. The byte compiler frequently (?usually) reports incorrect line/column numbers in its warning messages. This is due to the kludge it uses to keep track of them. The only current candidate for a fix is for the reader, on a flag being bound to non-nil, to return "symbols with position" rather than standard symbols. The "position" associated with the symbol is it's textual offset from the beginning of the construct in the source file being read. These symbols with position are implemented as pseudovectors with type PVEC_SYMBOL_WITH_POS and behave as ordinary symbols for all purposes, except for when a warning message is being output, when the postion supplies a correct file/line number for the message. This works and works well. However it causes an unacceptable slowdown in Emacs (around 8 - 15 per cent). I'm working on a fix for this, and have made substantial progress. The topic was discussed at length in emacs-devel starting November last year in posts whose Subject: contained "scratch/accurate-warning-pos". -- Alan Mackenzie (Nuremberg, Germany).