Summary: | emacs-24.1_rc fails to start, bidi_mirror_table is nil | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Fred Krogh <fkrogh> |
Component: | Current packages | Assignee: | Emacs project <emacs> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
The debug info requested
emacs-24.1_rc build log More detail from gdb From emacs-updater -p The find results |
Description
Fred Krogh
2012-06-04 21:41:43 UTC
Could you post a gdb backtrace ("bt full") please? Preferably, with Emacs compiled with -ggdb. I'm sorry, but I will need help to do what is requested. Do I just change CFLAGS and emerge emacs? If so perhaps you would like to suggest precisely the flags you want. And I don't know what a gdb backtrace ("bt full") is. Give me more detail and I would be happy to comply. (In reply to comment #2) > I'm sorry, but I will need help to do what is requested. Do I just change > CFLAGS and emerge emacs? Right, just add "-ggdb" to CFLAGS. > If so perhaps you would like to suggest precisely the flags you want. > And I don't know what a gdb backtrace ("bt full") is. Give me more detail > and I would be happy to comply. Simply type "bt full" in gdb, after the program got the SIGABRT. Created attachment 314293 [details]
The debug info requested
I've compiled emacs with CFLAGS="-ggdb -march=native -pipe"
I've run gdb emacs, and then run -Q. On the crash run bt-full.
The attached result, is certainly no help to me. Perhaps I need to compile other packages with -ggdb?
(In reply to comment #4) > The attached result, is certainly no help to me. Yes, I don't get any clue where it crashes. Also something is strange there; at least some of the stack frames should contain useful information. So, can you attach Emacs' build.log please? What is the output of "eselect emacs list"? Can you run "emacs --version", or does it crash? Created attachment 314327 [details]
emacs-24.1_rc build log
mon1 ~ # eselect emacs list
Available Emacs symlink targets:
[1] emacs-23
[2] emacs-24 *
mon1 ~ # emacs --version
GNU Emacs 24.1.1
Sorry this took so long. My internet has been down.
Oops, I forgot to mention that in addition to -ggdb in CFLAGS, you also need to add "nostrip" (or "splitdebug") to FEATURES. Could you recompile Emacs with these settings and do a gdb backtrace again? (See also <http://www.gentoo.org/proj/en/qa/backtraces.xml>.) Created attachment 314343 [details]
More detail from gdb
So it calls abort in line 763 of bidi.c. The relevant code is: bidi_mirror_table = uniprop_table (intern ("mirroring")); if (NILP (bidi_mirror_table)) abort (); staticpro (&bidi_mirror_table); This doesn't look like a Gentoo specific problem, so I've forwarded this upstream (especially because the bidi code is new in Emacs 24). <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11634> OK, upstream says that this could be due to a misplaced environment variable like EMACSLOADPATH. What is the output of: $ printenv | grep -i EMACS Can you successfully start Emacs with one of the following commands? $ env -i HOME=$HOME DISPLAY=$DISPLAY TERM=$TERM emacs -Q $ xrdb </dev/null; emacs -Q INFOPATH=/usr/share/info:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.22/info:/usr/share/info/emacs-23 Neither of the suggested commands worked -- same failure, Fatal error (6)Aborted I changed the emacs-23 at the end of INOFPATH to emacs-24 and that gave no difference. However export EMACSLOADPATH=/usr/share/emacs/24.1/lisp/ works! So how was that supposed to get set? Many thanks! One more problem. Emacs-24.1 does not seem to find the stuff in /usr/share/emacs/site-lisp. Is there something extra that needs to be said? Thanks. Well, it shouldn't be necessary to set EMACSLOADPATH in the first place. Emacs should be able to determine the load-path automatically. So setting that variable is only a workaround for something that goes very wrong. You should have a file /usr/share/emacs/24.1/src/epaths.h (since you've built emacs with USE=source). Can you look up what is defined there for PATH_LOADSEARCH and PATH_DUMPLOADSEARCH? #define PATH_LOADSEARCH "/etc/emacs:/usr/share/emacs/site-lisp:/usr/share/emacs/24.1/l isp:/usr/share/emacs/24.1/leim" /* Like PATH_LOADSEARCH, but used only during the build process when Emacs is dumping. Configure (using "make epaths-force") sets this to $buildlisppath, which normally has the value: <srcdir>/lisp. */ #define PATH_DUMPLOADSEARCH "/var/tmp/portage/app-editors/emacs-24.1_rc/work/emacs-24.1/lisp" Is there some way to check that these are actually getting set? (In reply to comment #14) > #define PATH_LOADSEARCH > "/etc/emacs:/usr/share/emacs/site-lisp:/usr/share/emacs/24.1/l > isp:/usr/share/emacs/24.1/leim" > > /* Like PATH_LOADSEARCH, but used only during the build process > when Emacs is dumping. Configure (using "make epaths-force") sets > this to $buildlisppath, which normally has the value: <srcdir>/lisp. > */ > #define PATH_DUMPLOADSEARCH > "/var/tmp/portage/app-editors/emacs-24.1_rc/work/emacs-24.1/lisp" These look good. (Assuming that the line break in "l ... isp" is an artefact of copy-and-paste and doesn't exist in the file.) > Is there some way to check that these are actually getting set? There is, but it's a little tedious: 1. Extract the file emacs-24.1/src/.gdbinit from the emacs-24.1-rc tarball. (This will be needed for printing of lisp variables.) 2. $ gdb emacs 3. (gdb) break init_lread 4. (gdb) run -Q It should stop in function init_lread in lread.c. 5. (gdb) finish Should be in main program in emacs.c now. 6. (gdb) source /path/to/.gdbinit (The path where you've saved the .gdbinit file from step 1.) 7. (gdb) pv load-path Another thing that you could check is if anything in the site-lisp directories causes bad effects, by temporarily renaming them (don't forget to rename them back when finished): $ mv /usr/share/emacs/site-lisp /usr/share/emacs/site-lisp.safe $ mv /etc/emacs /etc/emacs.safe I'm hoping to avoid the business of unpacking the tar.gz file, and getting .gdbinit and re-emerging emacs with the --ggdb flag. I have discovered that it will work from a root terminal window if I am in /usr/share/emacs/site-lisp. Doing the same thing as a normal user does not pick up what I would like it too from site-lisp. And no matter who the user is, that window needs to have export EMACSLOADPATH=/usr/share/emacs/24.1/lisp/ prior to using emacs, or emacs doesn't even get started. Does all of this suggest anything. (I'm a bit slow in responding, as my internet is up and down on a regular basis. Allegedly this gets fixed "soon".) I'm hoping to avoid the business of unpacking the tar.gz file, and getting .gdbinit and re-emerging emacs with the --ggdb flag. I have discovered that it will work from a root terminal window if I am in /usr/share/emacs/site-lisp. Doing the same thing as a normal user does not pick up what I would like it too from site-lisp. And no matter who the user is, that window needs to have export EMACSLOADPATH=/usr/share/emacs/24.1/lisp/ prior to using emacs, or emacs doesn't even get started. Does all of this suggest anything. (I'm a bit slow in responding, as my internet is up and down on a regular basis. Allegedly this gets fixed "soon".) Please try if you can start Emacs after moving the site-lisp directories out of the way, as suggested in comment #16. Sorry, I did do that. Emacs started, but in the messages buffer said Warning: Lisp directory `/etc/emacs' does not exist. Warning: Lisp directory `/usr/share/emacs/site-lisp' does not exist. This warning is not there when I move these back. (In reply to comment #20) > Sorry, I did do that. Emacs started, Just to make sure, this is without setting EMACSLOADPATH? > but in the messages buffer said > > Warning: Lisp directory `/etc/emacs' does not exist. > Warning: Lisp directory `/usr/share/emacs/site-lisp' does not exist. Yes, these warnings are expected. Yes this worked even when EMACSLOADPATH was not set. But with these directories there, EMACSLOADPATH is needed to get emacs started. Hm, I'd really like to reproduce the problem. Maybe the most efficient way would be if you could send me a tarball of your /usr/share/emacs/site-lisp and /etc/emacs directories. Alternatively, what is the output of "emacs-updater -p"? (The emacs-updater command is provided by package app-admin/emacs-updater.) Created attachment 314579 [details]
From emacs-updater -p
I believe that when I ran emacs-updater in the past there were four packages that failed in the emerge. With the earlier emacs selected, emacs-updater could update all without problems.
I am trying to send the tar file, but my internet connection is really flaky, and so far the best it has managed is to send 7% before crashing. I'll try some more. (In reply to comment #24) > Created attachment 314579 [details] > From emacs-updater -p Something is very wrong there. For example the following file shouldn't be in site-lisp: > Found simple.elc (compiled by Emacs 23.3.1) What does "find /usr/share/emacs/site-lisp -ls" output? (In reply to comment #25) > I am trying to send the tar file, but my internet connection is really > flaky, and so far the best it has managed is to send 7% before crashing. > I'll try some more. Maybe this isn't necessary, please post the output of "find" first. Created attachment 314589 [details]
The find results
I this helps.
(In reply to comment #27) > Created attachment 314589 [details] > The find results Oh my, how did all that stuff get into there? Looks like there are at least two Emacs 23 directory trees, which will confuse Emacs 24. I suggest that you remove at least all of the following: /usr/share/emacs/site-lisp/etc /usr/share/emacs/site-lisp/not-needed-23.3 /usr/share/emacs/site-lisp/leim /usr/share/emacs/site-lisp/lisp /usr/share/emacs/site-lisp/site-lisp I'd guess that after doing this, Emacs 24 will properly start. I have no idea how all that stuff got in there. I'm sorry that I've wasted so much or your time on this, but very grateful to you for getting it resolved. All works perfectly now. Allow me a final note: There shouldn't be any files under /usr/share/emacs other than those installed there by Portage. All local stuff should go to /usr/local. Emacs can be made aware of it by adding a line like (add-to-list 'load-path "/usr/local/share/emacs/my/site-lisp/path") for each local lisp directory, either to /etc/emacs/site-start.el or to your ~/.emacs file. I've moved what I know is possible into /usr/local/share/emacs/site-lisp. All seems to work except for the mouse wheel and my color theme when editing as root, which I very rarely do. Attempted use of the mouse wheel gives Symbol's functino definition is void: screen-width If you have a quick idea on how to fix this it would be much appreciated, I've given up figuring it out myself. Seems that one of your local files uses function "screen-width", which is obsolete since 1993 and was finally removed in Emacs 24. Thanks, not only did you find the problem, but I now have some idea how to track down similar problems should they occur. Sroll-in-place was the problem and it does not appear to be necessary any more. I love my new emacs! |