bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...))

bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...))

[Drew Adams]

I ran into this when using my setup, not emacs -Q

Debugger entered--Lisp error: (wrong-type-argument stringp (require . fit-frame))
  file-name-nondirectory((require . fit-frame))
  file-name-sans-extension((require . fit-frame))
  help-fns--autoloaded-p(message-tab 
                         "d:/Emacs-24-2014-01-23/share/emacs/24.3.50/lisp/gnus/message.el")
  describe-function-1(message-tab)
  describe-key("	" 1 nil)
  call-interactively(describe-key nil nil)
  command-execute(describe-key)

I do redefine `describe-function-1', but I don't see why that should be
involved here.  It seems to me that the call to `help-fns--autoloaded-p'
is valid, and from then on only vanilla code is involved, AFAIK.

`help-fns--autoloaded-p' does this, at the start:

(let* ((file (file-name-sans-extension (file-truename file)))

From the above backtrace, I can only guess that `file-truename' applied
to that file name must be returning a cons.  However, if I use `M-:' to
evaluate:

(file-truename "d:/Emacs-24-2014-01-23/share/emacs/24.3.50/lisp/gnus/message.el")

then I get the same absolute file name back - no cons.  So I'm puzzled.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-01-23 on ODIEONE
Bzr revision: 116129 monnier@iro.umontreal.ca-20140123150141-qopqqhpm8jqo8a18
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...))

[Drew Adams]

And in fact, if I do not redefine `describe-function-1', i.e., if I
evaluate the original definition, then I get the same error.

I did `debug-on-entry' for `help-fns--autoloaded-p' and then traced
things until the error was produced.  This is what I saw:

All of the calls to `file-truename' that I saw returned the right values.

There were multiple calls to `file-name-sans-extension', each of which,
except for the last, was passed an absolute file name and returned the
right value.  The last of these correct calls was this one:

Debugger entered--entering a function:
* file-name-sans-extension("d:/Emacs-24-2014-01-23/share/emacs/24.3.50/lisp/emacs-lisp/cl-indent.elc")

That returned, correctly,
"d:/Emacs-24-2014-01-23/share/emacs/24.3.50/lisp/emacs-lisp/cl-indent"

(None of the calls involved file handlers or symlinks, FWIW.)

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))
* #[514...]
* apply(#[514...] (message-tab "d:/Emacs-24-2014-01-23/share/emacs/24.3.50/lisp/gnus/message.el"))
* help-fns--autoloaded-p(message-tab "d:/Emacs-24-2014-01-23/share/emacs/24.3.50/lisp/gnus/message.el")
  describe-function-1(message-tab)
  describe-key("	" 1 nil)
  call-interactively(describe-key nil nil)
  command-execute(describe-key)

That is, as soon as the previous call to file-name-sans-extension
returned, correctly (and I traced that call step by step, using `d'),
`d' in the debugger came up with what you see above.

I also tried `debug-on-entry' for `describe-function-1' (the vanilla
Emacs version) and then  `C-h f message-tab'.  Same thing.

My wild guess is that the problem comes somehow from using Cygwin (?).

bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...))

[Glenn Morris]

Sounds like a problem with your code.
Nothing can be done without a recipe to reproduce this.

bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...))

[Eli Zaretskii]

> Date: Sat, 25 Jan 2014 15:09:11 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> 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))
> * #[514...]
> * apply(#[514...] (message-tab "d:/Emacs-24-2014-01-23/share/emacs/24.3.50/lisp/gnus/message.el"))
> * help-fns--autoloaded-p(message-tab "d:/Emacs-24-2014-01-23/share/emacs/24.3.50/lisp/gnus/message.el")
>   describe-function-1(message-tab)
>   describe-key("	" 1 nil)
>   call-interactively(describe-key nil nil)
>   command-execute(describe-key)

Isn't it possible that you have that weird cons cell in your
load-history?  help-fns--autoloaded-p does this:

    (while (and load-hist (not found))
      (and (caar load-hist)
	   (equal (file-name-sans-extension (caar load-hist)) file)

So if some element in load-history is that cons cell, this code will
call file-name-sans-extension on that cons cell.

bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...))

[Drew Adams]

> > 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))
> 
> Isn't it possible that you have that weird cons cell in your
> load-history?  help-fns--autoloaded-p does this:
> 
>     (while (and load-hist (not found))
>       (and (caar load-hist)
> 	   (equal (file-name-sans-extension (caar load-hist)) file)
> 
> 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'?

bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...))

[Stefan Monnier]

> 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.

Look for current-load-list (since those sublists are first built on
current-load-list before being added to load-history).


        Stefan

bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...))

[Drew Adams]

> > 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.
> 
> Look for current-load-list (since those sublists are first built on
> current-load-list before being added to load-history).

Good to know.  But grepping for that also shows nothing in my
code or the BBDB code.

bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...))

[Stefan Monnier]

> Good to know.  But grepping for that also shows nothing in my
> code or the BBDB code.

Hmm... maybe the problem is with load-file-name?  Otherwise, I don't
know how such a thing got there.
In any case, please check first whether you really do have a non-string
in (mapcar #'car load-history).  If you do, that's your problem, and we
need to figure out how it got there.


        Stefan

bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...))

[Drew Adams]

> Hmm... maybe the problem is with load-file-name?  Otherwise, I don't
> know how such a thing got there.
> In any case, please check first whether you really do have a non-
> string in (mapcar #'car load-history).  If you do, that's your
> problem, and we need to figure out how it got there.

Unfortunately, that session is long gone, as I explained.
I likely won't be futzing with the BBDB code again soon, and
I can anyway not recall all of the things I did in that session
before getting the error.

If I see the problem again, it will likely be unrelated to BBDB,
and I will check more for wrt `load-history' structure problem.

bug#16553: 24.3.50; `file-truename' returns a cons? (wrong-type-argument stringp (...))

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

>> Isn't it possible that you have that weird cons cell in your
>> load-history?  help-fns--autoloaded-p does this:
>> 
>>     (while (and load-hist (not found))
>>       (and (caar load-hist)
>> 	   (equal (file-name-sans-extension (caar load-hist)) file)
>> 
>> 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.)

This doesn't seem likely to be an Emacs bug.  Closing, but please reopen
if it turns out to still be a problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/