Just for the record, the date ranges are indeed right, no need to make the leftmost date flexible --- at least if you take into account only Guix's repository.
There is a related item in help-guix ([1]), and there was an attempt made by me to get a backtrace and a strace --- although I still have to find out how to install debug symbols for GNU Emacs. As I replied there ([2]), it might be due to a change between 2017-10-10T08:25 BRT and 2017-10-30T16:27 BRST --- either in a Guix package definition or in the upstreams. As Mekeor Melire ([1] and Daniel Pimentel ([2]) pointed out it, might be an issue related to GTK+. But I also don't discard related components. One could list commits between the given dates by doing: --8<---------------cut here---------------start------------->8--- git log --after="2017-10-10T08:25 BRT" --before="2017-10-30T16:27 BRST" --8<---------------cut here---------------end--------------->8--- Now we must test by making local copies of the possibly affected package definitions, reverting the commits, and building our Emacs locally. [1] <https://lists.gnu.org/archive/html/help-guix/2017-11/msg00079.html>. [2] <https://lists.gnu.org/archive/html/guix-devel/2017-11/msg00313.html>. 2017-11-13T12:44:59-0200 Adonay Felipe Nogueira wrote: > 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>.
