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'?