Bug 147586 - high line-number-display-limit-width crashes emacs during ispell
Summary: high line-number-display-limit-width crashes emacs during ispell
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs   
(Show other bugs)
Version: 3
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-02-09 16:23 UTC by Michael Smolsky
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-04 00:59:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gdb backtrace (3.75 KB, text/plain)
2005-04-08 05:55 UTC, Jens Petersen
no flags Details

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 4 Jens Petersen 2005-04-08 05:55:59 UTC
Created attachment 112846 [details]
gdb backtrace

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.


Note You need to log in before you can comment on or make changes to this bug.