From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?andr=C3=A9s_?= =?UTF-8?Q?ram=C3=ADrez?= Newsgroups: gmane.emacs.bugs Subject: bug#14120: invalid load-history in emacsen that CANNOT_DUMP Date: Mon, 17 Feb 2020 17:14:54 +0000 Organization: bien.comun.org Message-ID: <86zhdhi19t.fsf@gmail.com> References: <87fvz9rhqq.fsf@olor.terpri.org> <861rqtjq10.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="28883"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 14120@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 17 18:16:35 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j3k0Y-0007Od-QI for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 17 Feb 2020 18:16:34 +0100 Original-Received: from localhost ([::1]:48966 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3k0X-0001zp-Fx for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 17 Feb 2020 12:16:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35864) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3k03-0001eK-8z for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2020 12:16:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3k02-0003xx-45 for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2020 12:16:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33183) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j3k01-0003xn-PZ for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2020 12:16:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j3k01-0007pK-KN for bug-gnu-emacs@gnu.org; Mon, 17 Feb 2020 12:16:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?andr=C3=A9s_?= =?UTF-8?Q?ram=C3=ADrez?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Feb 2020 17:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14120 X-GNU-PR-Package: emacs Original-Received: via spool by 14120-submit@debbugs.gnu.org id=B14120.158195970730018 (code B ref 14120); Mon, 17 Feb 2020 17:16:01 +0000 Original-Received: (at 14120) by debbugs.gnu.org; 17 Feb 2020 17:15:07 +0000 Original-Received: from localhost ([127.0.0.1]:39156 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3jz9-0007o5-83 for submit@debbugs.gnu.org; Mon, 17 Feb 2020 12:15:07 -0500 Original-Received: from mail-qv1-f54.google.com ([209.85.219.54]:36871) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3jz7-0007nK-68 for 14120@debbugs.gnu.org; Mon, 17 Feb 2020 12:15:05 -0500 Original-Received: by mail-qv1-f54.google.com with SMTP id m5so7894770qvv.4 for <14120@debbugs.gnu.org>; Mon, 17 Feb 2020 09:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:organization:references:date :message-id:mime-version; bh=tKp0rQqWaOIEUP+hXF9PTHyHdU2XoD59uH9cdGHjg7o=; b=CQgCjS8xaiI7IF2Rv7zvxIV/DIzYh5eu/fmRwM2iTmHecvdM4IYRn2ZAna5UwRd+ug rpS1AEhp7OyA+Ws0FZ3ixrwdtU249l6kaknkPZ8FRm+olRg/PCk7Mw5g8rGSqVRHu4uW kXBwvzo363wHXpuKKfaXjdN/odXB1qD8nOfvDKAkaaPVyPUoKCStosby2DeyV5pdfluS r7jGe+2stSa+ZcCxO85nwlmR4Tr23c6q5z3qhXnfABEpogI7vyj50ILudJOhZV1yQAdw w2s+FSAw7kXSbwwNJBNguHC51gDtes8CKfIPoMWU1nFlHnWUpE9L3epHqVCHZkAK3fpU /5ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:organization :references:date:message-id:mime-version; bh=tKp0rQqWaOIEUP+hXF9PTHyHdU2XoD59uH9cdGHjg7o=; b=qj0XwO++J0hnvGokzGlrejQJKGzL2A0qYu6uErebSTMr4h2u+aqmklTYL66uvJ4p1D 6JF2dAHy9axGMBNi1rToZEcKri4XYJZgD2UNZ+ubz2LUyXGSNffkenoezvP+Bhdn1kPD EtlkYOfRMvqTR85hdPFjcPDW6iQm/4h3Dooajv3Bu4kqLwqV01wt1p7kZaIR6ApNfVNT N180Oq1U13J7rGR4NvuVz6e70UZes8s4Uymol81EHAu5KdcGb83nwc4BYe5avm1FylO8 iikLvpyfe77ijCEeHSQh3AcDm/iXk1YB3ONiq/WSTrLKR52nuveand8CFuk8IJcidd2a KRdg== X-Gm-Message-State: APjAAAVE2RlksK9QAP0BxbKp8a8KBuYet86uPUlqDYYeZ8dALSCqWZjT RePKORgToLaiAtrbOWNlz5/w47xH X-Google-Smtp-Source: APXvYqx5bghjFk7uCVnc6dmXF71Ibqx08tNMRybrTMaVM4kx7sQ2bEK4bSRb+oQtmfR+nFB9qKnTkQ== X-Received: by 2002:a0c:fc12:: with SMTP id z18mr13479355qvo.17.1581959699436; Mon, 17 Feb 2020 09:14:59 -0800 (PST) Original-Received: from sacsa.n800.arm.processor.yandex.fm ([190.236.255.87]) by smtp.gmail.com with ESMTPSA id 139sm522365qkg.79.2020.02.17.09.14.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Feb 2020 09:14:58 -0800 (PST) In-Reply-To: X-Attribution: INKA X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:176150 Archived-At: Hi Stefan. Stefan> Any chance you can try and investigate where/why/how that Stefan> spurious value gets pushed to `load-history`? Yes. I am going to try. Stefan> AFAICT the only place where `load-history` gets modified is in Stefan> lread.c:build_load_history. Could you add some assertions Stefan> there to try and catch the sucker? I was aware of that. At that moment. I pointed to lread.c also. But this seems too happen during startup (reading the dot emacs setup). I am going to list what I would need to do for reaching the goal: 1. Recompile Emacs23 (for enabling debugging-symbols) 2. Put a breakpoint on lread.c:build_load_history and watch how many times it is called and with wich params. It seems a very long list of params 3. After it. I suppose I should start emacs23 -Q and try lo call one by one lread.c:build_load_history with those params. And after every function invocation I would need to check if that symbol(the spurious one that corrupts the list) have got inside the loads-history-list. An idea: As I have a running emacs23 session right now. --8<---------------cut here---------------start------------->8--- (defun load-history-filename-element (file-regexp) "Get the first elt of `load-history' whose car matches FILE-REGEXP. Return nil if there isn't one. NOTE2ME: upd stringp condition cos of error on tramp" (let* ((loads load-history) (load-elt (and loads (car loads)))) (save-match-data (while (and loads (or (null (and (car load-elt) (stringp (car load-elt)))) (not (string-match file-regexp (car load-elt))))) (setq loads (cdr loads) load-elt (and loads (car loads))))) load-elt)) --8<---------------cut here---------------end--------------->8--- The function above could be modified for removing the stringp validation. And every time load-history-filename-element is called when an error happens that function show me the file on the history to which the spurious symbol belongs to? What Do You think? AR