Bug 137327
| Summary: | emacs hangs when ispelling TeX files | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David Monniaux <david.monniaux> |
| Component: | aspell | Assignee: | Ivana Varekova <varekova> |
| Status: | CLOSED RAWHIDE | QA Contact: | Ben Levenson <benl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2 | CC: | havill, petersen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-07-01 08:46:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This sounds a bit like bug 54391, which I couldn't reproduce... Do the same thing happen with "emacs -q --no-site-file" for you? Perhaps it is a aspell issue on x86_64? Can you reproduce on a ix86 box? :) Perhaps you'd like to try with say FC3test3 or the packages in rawhide now to see if it is any better. The same problem happens with "emacs -q --no-site-file" on the AMD64 machine. I do not have a non-AMD64 x86 box with Fedora Core 2 installed. This is a workplace machine, it's not easy for me to go and install experimental machines. I can confirm the hang on AMD64 and working on 32-bit Athlon. Steps: $ touch empty.tex $ emacs empty.tex type "barf" hit ESC hit $ Result on single Athlon XP 2400+: it nicely confirms that the word "barf" is correctly spelled. Result on dual Opteron 248: prints 'Checking spelling of BARF...', then emacs hangs with 100% CPU usage. Both machines are running Fedora Core 2, package versions emacs-21.3-12, aspell -0.50.3-19.1. Opteron is running 64-bit version. If I edit 'empty.txt' instead of 'empty.tex' the Opteron does not hang. emacs loops on a read(3, "", 1024)=0 system call. File descriptor 3 is a pipe (read end) to ispell, set to non-blocking mode. Ok, I see. Does FC2 aspell work ok by itself on amd64? It looks like aspell works well standalone. At least, I can launch it on the same file and it works ok. The problem does *not* appear on Debian pure64 with the following packages: emacs21 21.3+1-5.0.0.1.pure64 The GNU Emacs editor aspell 0.50.5-4 GNU Aspell spell-checker This seems to be an aspell issue as I suspected: Downgrading to aspell-0.50.3-19.1 (fc2) on an fc3 install and I can reproduce the problem. (I forgot to add that it works in FC3.) Can anybody reproduce this bug with the latest aspell package (aspell-0.50.5)? Ivana Varekova I'm closing this bug. If there is some problem please reopen it. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20040913 Description of problem: When editing any .tex file, hitting M-$ (or any ispell function) hangs the process (C-g can recover from it). M-x flyspell-mode hangs the process in a way not recoverable from C-g. The symptoms disappear if one disables the Ispell TeX parser: (add-hook 'tex-mode-hook (function (lambda () (setq ispell-parser nil)))) (add-hook 'TeX-mode-hook (function (lambda () (setq ispell-parser nil)))) (add-hook 'LaTeX-mode-hook (function (lambda () (setq ispell-parser nil)))) Version-Release number of selected component (if applicable): emacs-21.3 How reproducible: Always Steps to Reproduce: 1.Open a .tex file 2.Hit M-$ on any word in the text (say, APPLICATION) 3. Actual Results: Emacs shows "checking APPLICATION..." and hangs. Expected Results: It should tell me the word is correct and go on editing. Additional info: