bug#34094: 27.0.50; (wrong-type-argument stringp (require . elec-pair)) with describe-function (and other commands)

[Eli Zaretskii <eliz@gnu.org>]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: 34094@debbugs.gnu.org
> Date: Thu, 17 Jan 2019 06:52:36 +0100
> 
> >> Using load-path (/usr/local/share/emacs/27.0.50/site-lisp
> >> /usr/local/share/emacs/site-lisp /home/horn/Repos/el/emacs/lisp
> >> /home/horn/Repos/el/emacs/lisp/emacs-lisp
> >> /home/horn/Repos/el/emacs/lisp/progmodes
> >> /home/horn/Repos/el/emacs/lisp/language
> >> /home/horn/Repos/el/emacs/lisp/international
> >> /home/horn/Repos/el/emacs/lisp/textmodes /home/horn/Repos/el/emacs/lisp/vc)
> >> Loading emacs-lisp/byte-run...
> >> Loading emacs-lisp/byte-run...done
> >> Loading emacs-lisp/backquote...
> >> Loading emacs-lisp/backquote...done
> >> ...
> >
> > This part is expected, and is not a bug.
> 
> So with pdumper, I should always invoke ~/Repos/el/emacs/src/emacs
> instead of the symlink in my PATH pointing to it?

Currently, yes.  This is how the code was written.  Whether we want to
support the symlink case is an open question, worth discussing.

> When I start emacs using my symlink pointing to
> ~/Repos/el/emacs/src/emacs, I get the above output and the original
> wrong-type-argument error according to my recipe.

To be absolutely clear: the wrong-type-argument error is also a bug,
and should be investigated.  I hope Daniel will be able to look into
that.

> >> (gdb) run
> >> Starting program: /home/horn/Repos/el/emacs/src/emacs 
> >> [Thread debugging using libthread_db enabled]
> >> Using host libthread_db library "/usr/lib/libthread_db.so.1".
> >> [New Thread 0x7fffeea70700 (LWP 25211)]
> >> [Detaching after vfork from child process 25212]
> >> [New Thread 0x7fffee22d700 (LWP 25213)]
> >> [New Thread 0x7fffed2b2700 (LWP 25214)]
> >> [Detaching after vfork from child process 25215]
> >> [Detaching after vfork from child process 25216]
> >> [Detaching after vfork from child process 25217]
> >> [Detaching after vfork from child process 25218]
> >> [Detaching after vfork from child process 25219]
> >
> > Any idea what are all those vforks about?  Is this something caused by
> > your init files?
> 
> I don't get them with run -Q, so I guess it's something in my init file.
> When I try again, now I only get 21 vforks instead of the 132 I've had
> before.
> 
> If I were keen to know what's the cause, how would I find out?

If your customizations cause a lot of processes to be launched at
startup, then the above is expected.  Otherwise, I'd suggest to look
for some code which might launch such processes which you didn't
intend.

Thanks.