From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...)) Date: Sun, 26 Jan 2014 10:33:04 -0800 (PST) Message-ID: <8ea26242-db04-4456-b4dd-3680fbd76949@default> References: <> <> <<83txcqaazz.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1390761257 8140 80.91.229.3 (26 Jan 2014 18:34:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Jan 2014 18:34:17 +0000 (UTC) Cc: 16553@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 26 19:34:23 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1W7UXH-0007Tz-9B for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Jan 2014 19:34:23 +0100 Original-Received: from localhost ([::1]:55797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7UXG-0000KN-Tt for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Jan 2014 13:34:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7UX5-0000KC-9j for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 13:34:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7UWw-0001Yh-N1 for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 13:34:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7UWw-0001Yc-JV for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 13:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W7UWw-00078B-0s for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 13:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Jan 2014 18:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16553 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 16553-submit@debbugs.gnu.org id=B16553.139076118827341 (code B ref 16553); Sun, 26 Jan 2014 18:34:01 +0000 Original-Received: (at 16553) by debbugs.gnu.org; 26 Jan 2014 18:33:08 +0000 Original-Received: from localhost ([127.0.0.1]:36860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7UW3-00076t-CC for submit@debbugs.gnu.org; Sun, 26 Jan 2014 13:33:08 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:36552) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7UW0-00076g-GF for 16553@debbugs.gnu.org; Sun, 26 Jan 2014 13:33:05 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0QIX3HX015984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 26 Jan 2014 18:33:03 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0QIX2lD007248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Jan 2014 18:33:03 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0QIX2ux007237; Sun, 26 Jan 2014 18:33:02 GMT In-Reply-To: <<83txcqaazz.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:84050 Archived-At: > > The next thing I saw in the debugger was this bizarre call to > > `file-name-sans-extension': > > > > Debugger entered--entering a function: > > * file-name-sans-extension((require . fit-frame)) >=20 > Isn't it possible that you have that weird cons cell in your > load-history? help-fns--autoloaded-p does this: >=20 > (while (and load-hist (not found)) > (and (caar load-hist) > =09 (equal (file-name-sans-extension (caar load-hist)) file) >=20 > So if some element in load-history is that cons cell, this code > will call file-name-sans-extension on that cons cell. Yes. Bravo and thank you once again, Eli. I was wondering about that cons. I think you nailed it. (That cons would not be an entry, however, but the car of an entry, for the error to occur.) I don't have that session anymore (and it involved quite a bit of setup to reach that state). But yes, in any given session I do see entries that have 4th,, 5th, etc. subentries that are similar - e.g.: ("d:/Emacs-24-2014-01-23/share/emacs/24.3.50/lisp/sort.elc" sort-fold-case sort-fold-case (t . sort-subr) (defun . sort-subr) (defun . sort-build-lists) (defun . sort-reorder-buffer) (t . sort-lines) (defun . sort-lines) (t . sort-paragraphs) ...) That corresponds to what the `load-history' doc describes, so I don't really think (require . fit-frame) should be considered a "weird cons cell", provided it occurs at the right place. But judging from the definition of `help-fns--autoloaded-p', which loops over the `load-history' entries (it should not descend inside entries, AFAICS), the error would be raised only if `load-history' somehow had that cons cell as the car of one of its entries, instead of as the cadr, caddr, etc. AFAIK, I do not have any code that fiddles with `load-history', but that session that I reported from involved loading a bunch of the BBDB code, so I cannot speak for that. Grepping the BBDB files, I find no occurrence of `load-history' there either. I don't see a problem with the `help-fns--autoloaded-p' code, offhand. But maybe it should made be bullet-proof, ensuring that (caar load-hist) is a string before calling `file-name-sans-extension'?