|Summary:||high line-number-display-limit-width crashes emacs during ispell|
|Product:||[Fedora] Fedora||Reporter:||Michael Smolsky <sitrash>|
|Component:||emacs||Assignee:||Jens Petersen <petersen>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-10-04 00:59:50 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Michael Smolsky 2005-02-09 16:23:35 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20040921 Description of problem: M-x ispell-buffer crashes emacs, if .emacs file contains a line with a very large line-number-display-limit setting Version-Release number of selected component (if applicable): emacs-21.3-21.FC2, emacs-common-21.3-21.FC2, emacs-leim-21.3-21.FC2 How reproducible: Always Steps to Reproduce: 1. Create ~/.emacs, that contains a single line (setq line-number-display-limit-width 99999999) 2. Start emacs 3. Type in a line into emacs, right into *scratch* buffer. My line was: alsdkf;lakdf ;lakdf;alkf ;asldf;lakdf 4. Hit M-x ispell-buffer 5. Go through the words in the line using "space" key 6. Observe the crash 7. Remove a couple of '9's from ~/.emacs 8. Repeat the steps 2--5. Observe NO crash instead of step 6 Actual Results: Emacs window disappeared. The following was output to the shell prompt, from which emacs was started: >emacs Warning: Cannot convert string "fontset-18" to type FontStruct Fatal error (6).Aborted Expected Results: Emacs window should have stayed alive. An error message warning on too high a parameter for ispell-buffer-display-limit should have been visible somewhere A cup of hot coffee should have appeared on my desk. Additional info: emacs' *Messages* window: (emacs) Loading disp-table...done Loading tool-bar...done Loading image...done Loading tooltip...done Loading /usr/share/emacs/site-lisp/site-start.d/lang-coding-systems-init.el (source)... Loading encoded-kb...done Loading /usr/share/emacs/site-lisp/site-start.d/lang-coding-systems-init.el (source)...done Loading /usr/share/emacs/site-lisp/site-start.d/php-mode-init.el (source)...done Loading /usr/share/emacs/site-lisp/site-start.d/po-mode-init.el (source)...done Loading /usr/share/emacs/site-lisp/site-start.d/psgml-init.el (source)...done Loading /usr/share/emacs/site-lisp/site-start.d/python-mode-init.el (source)...done Loading /usr/share/emacs/site-lisp/site-start.d/rpm-spec-mode-init.el (source)...done Loading mwheel...done Loading jka-compr...done For information about the GNU Project and its goals, type C-h C-p. call-interactively: Quit keyboard-quit: Quit
Comment 1 Jens Petersen 2005-04-08 05:13:52 UTC
Reproduced - this still happens with current cvs emacs too. Do you see this kind of crashing with saner values of line-number-display-limit-width too?
Comment 3 Jens Petersen 2005-04-08 05:54:42 UTC
Additional note: emacs also often also crashes when doing completions. Eg "M-x c Tab" causes a reproducible crash.
Comment 5 Jens Petersen 2005-10-03 08:14:11 UTC
Still happens with emacs-22.0.50-0.20050714 snapshot. Does it happen with sane values of line-number-display-limit-width?
Comment 6 Michael Smolsky 2005-10-03 13:54:30 UTC
(In reply to comment #5) > Still happens with emacs-22.0.50-0.20050714 snapshot. > > Does it happen with sane values of line-number-display-limit-width? Please, see items 7 and 8 on the initial bug report in "Bug Comments" section
Comment 7 Jens Petersen 2005-10-04 00:59:50 UTC
Oh, yes thanks. Based on that I propose closing then.
Comment 8 Jens Petersen 2005-10-04 01:03:13 UTC
BTW this was reported on emacs-devel with no response: http://lists.gnu.org/archive/html/emacs-devel/2005-04/msg00279.html But if you're not enable to produce with vanilla emacs built with from the upstream tarball, please re-open.
Comment 9 Jens Petersen 2005-10-04 01:05:12 UTC
> BTW this was reported on emacs-devel with no response: Sorry there was one response saying he couldn't reproduce.
Comment 10 Michael Smolsky 2005-10-04 13:54:03 UTC
(In reply to comment #7) > Oh, yes thanks. Based on that I propose closing then. I think emacs should NOT be crashing even if the parameter in the .emacs file is unreasonably high. As I suggested in the bug report, execution of such a command should print an error message some how, but not crash the editor. I think the present behavior is a bug.
Comment 11 Jens Petersen 2005-10-05 00:41:52 UTC
I agree it shouldn't crash and if you can help to get a patch to fix this I would be happy to include it. I don't know if an error message needs to appear, it should "just work" or ignore very large values: perhaps that would be a suitable workaround? Anyway I recommend getting this fixed in cvs emacs first by discussing it on emacs-devel list.