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

[Tassilo Horn <tsdh@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> So when I start emacs from anywhere but /home/horn/Repos/el/emacs/src/,
>> it'll print a lot of messages like:
>> 
>> Loading loadup.el (source)...
>> dump mode: nil
>> 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?

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.

>> When I start it from within /home/horn/Repos/el/emacs/src/ where the
>> emacs executable and emacs.pdmp exists, I get no such messages.
>> Then, however, I get a segfault for example when I start gnus.
>> Here's the xbacktrace from gdb:
>
> This is bug, of course.

Already fixed by Daniel.

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

Bye,
Tassilo