Bug 147586 - high line-number-display-limit-width crashes emacs during ispell
high line-number-display-limit-width crashes emacs during ispell
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
3
All Linux
low Severity medium
: ---
: ---
Assigned To: Jens Petersen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-09 11:23 EST by Michael Smolsky
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-03 20:59:50 EDT
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 01:55 EDT, Jens Petersen
no flags Details

  None (edit)
Description Michael Smolsky 2005-02-09 11:23:35 EST
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 01:13:52 EDT
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 01:54:42 EDT
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 01:55:59 EDT
Created attachment 112846 [details]
gdb backtrace
Comment 5 Jens Petersen 2005-10-03 04:14:11 EDT
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 09:54:30 EDT
(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-03 20:59:50 EDT
Oh, yes thanks.  Based on that I propose closing then.
Comment 8 Jens Petersen 2005-10-03 21:03:13 EDT
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-03 21:05:12 EDT
> 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 09:54:03 EDT
(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-04 20:41:52 EDT
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.