help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: error running emacs installed with guix


From: Adonay Felipe Nogueira
Subject: Re: error running emacs installed with guix
Date: Thu, 23 Nov 2017 20:42:30 -0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

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>.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]