If you don't mind, I took the liberty to also try following your
suggestion.

Just to clarify: I'm currently using Emacs 25.3 from an old `guix pull'
--- the working derivation was created in my computer in
2017-10-10T08:25 BRT (Brasília Time, which is UTC -03:00) ---. The
problematic GNU Guix revision for Emacs seems to come from a commit
before 2017-10-30T16:27 BRST (Brasília Summer Time, currently UTC
-02:00), but not too far behind.

It's too bad that the current package definition for Emacs doesn't
follow the "release.revision-commit" versioning suggested in the
documentation for GNU Guix ([1]). We could have a chance to get the exact
revision if that versioning were present.

For the record, I don't know if this helps, but I noticed that my normal
user's profile generation "manifest" file changed the output of Emacs
version 25.3:

- working Emacs 25.3:
  /gnu/store/b1nbgnpifkisz4szmasxrwzqlgqagy8w-emacs-25.3

- problematic Emacs 25.3:
  /gnu/store/5746kfanppgapypjqhciarya48vp9xr3-emacs-25.3

Again, problematic Emacs 25.3 comes from a commit between
2017-10-10T08:25 BRT and 2017-10-30T16:27 BRST --- although I think it
would be a good idea to add some dates before the initial part of the
range so as to accommodate the time it takes for the Emacs derivation to
be made.

Now for the attempt to use GDB.

It's one of the fewer times I used GDB. I don't exactly know how to use
it efficiently, because I'm not a programmer, so forgive me for being
naive.

Attempting to use GDB to debug
"/gnu/store/5746kfanppgapypjqhciarya48vp9xr3-emacs-25.3/bin/emacs"
directly (be that with or without "./core") makes GDB complain the
executable format isn't recognized. I found that the "emacs" in question
is a wrapper script that uses yet another wrapper script (which
strangely seems to do/set the exact same variables as the parent
wrapper) which finally runs the real Emacs. This "double-wrapper" is
also present in the *working* Emacs 25.3.

So I had to attempt to simulate the wrapper scripts by making a text
file with the corresponding commands for GDB. The script is attached to
this message. The commented parts (those starting with "#") are the
parts I was unable to simulate --- because I know little about
GDB. Besides in the `set env' commands I kept the Bash-specific
${VARIABLE:+:} syntax, but I don't know if GDB supports it.

Having that GDB script ready, now I set the maximum size of core files
to "unlimited" for the current shell (just in case):

--8<---------------cut here---------------start------------->8---
ulimit -c unlimited
--8<---------------cut here---------------end--------------->8---

And run:

--8<---------------cut here---------------start------------->8---
gdb -iex "set logging on gdb_emacs.log.txt" \
    -iex "set pagination off" \
    -iex "set args -Qnw" \
    -x "gdb_cmds.txt" \
    -ex "run" \
    -ex "generate-core-file emacs_core_dump" \
    -ex "continue" \
    -ex "target core emacs_core_dump" \
    -ex "backtrace" \
    -ex "quit" \
    "/gnu/store/5746kfanppgapypjqhciarya48vp9xr3-emacs-25.3/bin/.emacs-25.3-real"
--8<---------------cut here---------------end--------------->8---

The log file is attached. I didn't attach the coredump (> 20 MiB), but
if you want me to do so, please send a reply asking for it.

I have also made an `strace' starting from the *wrapper* scripts, with:

--8<---------------cut here---------------start------------->8---
strace -f -o "strace_-f_gnu_store_5746kfa_emacs_-Qnw.txt" \
       "/gnu/store/5746kfanppgapypjqhciarya48vp9xr3-emacs-25.3/bin/emacs" \
       -Qnw
--8<---------------cut here---------------end--------------->8---

The log of `strace' is also attached.


I hope this helps.
Happy hacking! :)

[1] <https://www.gnu.org/software/guix/manual/html_node/Version-Numbers.html#Version-Numbers>.