GNU bug report logs - #15405
24.3; #[] freezes emacs

Previous Next

Full log

Message #47 received at 15405 <at> debbugs.gnu.org (full text, mbox):

From: Barry OReilly <gundaetiapo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stephen.berman <at> gmx.net, 15405 <at> debbugs.gnu.org, Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#15405: 24.3; #[] freezes emacs
Date: Fri, 20 Sep 2013 11:33:13 -0400

[Message part 1 (text/plain, inline)]

Here's what happens:
   - read1 reads the #[] and proceeds to create a vector of zero
     length
   - allocate_vectorlike has a special case for zero length vectors:
       if (len == 0)
         p = XVECTOR (zero_vector);
   - zero_vector is a global variable, so all zero length vectors
     point to it. This can be seen when evalling:
       (eq [] []) ; Evalutes to t
       (eq [1 2 3] [1 2 3]) ; Evaluates to nil
   - After read1 creates the zero_vector, it sets bits in the size
     field to indicate it is a PVEC_COMPILED pseudo vector
   - The global zero_vector is thereafter a PVEC_COMPILED pseudo
     vector, including the empty vector of the font data
   - Later, the font_list_entities function checks the size of the
     font data vector using ASIZE. It does not expect a pseudo vector,
     so it makes no such checks.
   - Because the pseudo vector bits are set, the size is very large
   - Indexing too far into the font data vector results in a core dump

What should the behavior be? Perhaps (eval #[]) should evaluate to []
instead of #[]?

Maybe an eassert in font_list_entities that its vector is not a pseudo
vector couldn't hurt either?

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.