[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: puzzle.el.

From: Kim F. Storm
Subject: Re: puzzle.el.
Date: 19 Jul 2004 11:10:44 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Matt Hodges <address@hidden> writes:

> After playing around with insert-sliced-image, I wrote a slide puzzle
> program (see attached).
> If the number of image slices is too large, Emacs can crash in the
> redisplay code. Evaluating the following:
>     (let ((puzzle-max-rows-columns 25)
>           (puzzle-rows 25)
>           (puzzle-columns 25))
>       (fset 'puzzle-randomize (lambda ()))
>       (puzzle))
> leads to a segmentation fault, and the following backtrace:
>     #0  0x080aaa21 in display_line (it=0xbfffe490) at xdisp.c:14527
>     #1  0x080a5e48 in try_window (window=141168948, pos={charpos = 
> -1073748848, bytepos = 1}) at xdisp.c:12219
>     #2  0x080a56c4 in redisplay_window (window=141168948, just_this_one_p=0) 
> at xdisp.c:11861

The problem is that the window's "glyph matrix" is too small.

The height and width of the glyph matrix is calculated from the smallest font 
that is available on the window's frame.

For example, if the smallest font is 10x10 and your window is 600x800, you will 
get a glyph matrix of approx 60x80.
Now, if you use a sliced image (or just many images which are less than 10x10 
in size, you can easily fill the
window with more than those 60x80 glyphs.

Since there is no bounds checking on inserting into a glyph matrix, emacs 
eventually traps in such cases.

I will see if there is a trivial fix...

Kim F. Storm <address@hidden> http://www.cua.dk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]