emacs-bug-tracker
[Top][All Lists]
Advanced

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

[Emacs-bug-tracker] bug#8344: closed ((substring ...) crashes on large v


From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#8344: closed ((substring ...) crashes on large vectors)
Date: Wed, 30 Mar 2011 00:54:03 +0000

Your message dated Tue, 29 Mar 2011 17:53:19 -0700
with message-id <address@hidden>
and subject line fix merged to trunk
has caused the GNU bug report #8344,
regarding (substring ...) crashes on large vectors
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
8344: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8344
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: (substring ...) crashes on large vectors Date: Fri, 25 Mar 2011 11:17:30 -0700 User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9
I found this problem while compiling the Emacs trunk with
gcc -Wstrict-overflow.

Currently, on a 64-bit machine, (substring VEC FROM TO)
fails if TO and FROM are valid indexes and
TO - FROM is 2**31 or greater.  On typical hosts there
can be buffer overruns or crashes.

The problem is that (substring ...) internally calls
(vector ...), and (vector ...) cannot create a vector
whose length is 2**31 or greater, because it follows
the Emacs convention that varargs functions count the
number of arguments using an 'int'.

The simplest and most general way to address this problem
is to change the Emacs convention to use EMACS_INT rather
than 'int' to count the number of arguments to a function.
I'm preparing a patch along those lines.  The changes
to lisp.h are below; the other changes should be
straightforward albeit tedious.

Before I work any more on this, can anyone see why not
to do this?

=== modified file 'src/lisp.h'
--- src/lisp.h  2011-03-22 09:08:11 +0000
+++ src/lisp.h  2011-03-24 08:54:15 +0000
@@ -964,7 +964,7 @@ struct Lisp_Subr
       Lisp_Object (*a7) (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, 
Lisp_Object, Lisp_Object, Lisp_Object);
       Lisp_Object (*a8) (Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object, 
Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object);
       Lisp_Object (*aUNEVALLED) (Lisp_Object args);
-      Lisp_Object (*aMANY) (int, Lisp_Object *);
+      Lisp_Object (*aMANY) (EMACS_INT, Lisp_Object *);
     } function;
     short min_args, max_args;
     const char *symbol_name;
@@ -1809,7 +1809,7 @@ typedef struct {
 
 /* Note that the weird token-substitution semantics of ANSI C makes
    this work for MANY and UNEVALLED.  */
-#define DEFUN_ARGS_MANY                (int, Lisp_Object *)
+#define DEFUN_ARGS_MANY                (EMACS_INT, Lisp_Object *)
 #define DEFUN_ARGS_UNEVALLED   (Lisp_Object)
 #define DEFUN_ARGS_0   (void)
 #define DEFUN_ARGS_1   (Lisp_Object)
@@ -2079,7 +2079,7 @@ struct gcpro
   volatile Lisp_Object *var;
 
   /* Number of consecutive protected variables.  */
-  int nvars;
+  EMACS_INT nvars;
 
 #ifdef DEBUG_GCPRO
   int level;
@@ -2860,7 +2860,7 @@ extern Lisp_Object internal_lisp_conditi
 extern Lisp_Object internal_condition_case (Lisp_Object (*) (void), 
Lisp_Object, Lisp_Object (*) (Lisp_Object));
 extern Lisp_Object internal_condition_case_1 (Lisp_Object (*) (Lisp_Object), 
Lisp_Object, Lisp_Object, Lisp_Object (*) (Lisp_Object));
 extern Lisp_Object internal_condition_case_2 (Lisp_Object (*) (Lisp_Object, 
Lisp_Object), Lisp_Object, Lisp_Object, Lisp_Object, Lisp_Object (*) 
(Lisp_Object));
-extern Lisp_Object internal_condition_case_n (Lisp_Object (*) (int, 
Lisp_Object *), int, Lisp_Object *, Lisp_Object, Lisp_Object (*) (Lisp_Object));
+extern Lisp_Object internal_condition_case_n (Lisp_Object (*) (EMACS_INT, 
Lisp_Object *), EMACS_INT, Lisp_Object *, Lisp_Object, Lisp_Object (*) 
(Lisp_Object));
 extern void specbind (Lisp_Object, Lisp_Object);
 extern void record_unwind_protect (Lisp_Object (*) (Lisp_Object), Lisp_Object);
 extern Lisp_Object unbind_to (int, Lisp_Object);
@@ -2870,7 +2870,7 @@ extern void do_autoload (Lisp_Object, Li
 extern Lisp_Object un_autoload (Lisp_Object);
 EXFUN (Ffetch_bytecode, 1);
 extern void init_eval_once (void);
-extern Lisp_Object safe_call (int, Lisp_Object *);
+extern Lisp_Object safe_call (EMACS_INT, Lisp_Object *);
 extern Lisp_Object safe_call1 (Lisp_Object, Lisp_Object);
 extern Lisp_Object safe_call2 (Lisp_Object, Lisp_Object, Lisp_Object);
 extern void init_eval (void);




--- End Message ---
--- Begin Message --- Subject: fix merged to trunk Date: Tue, 29 Mar 2011 17:53:19 -0700 User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
I committed a fix to the trunk for this,
as part of a recent merge (bzr 103776).

For Bug#8344, the merge uses size_t rather
than EMACS_INT for argument counts as I proposed earlier,
since the argument counts are always nonnegative
and are limited just by sizes that can be counted
at the C level.


--- End Message ---

reply via email to

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