public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: ak03@gte.com
To: gcc-gnats@gcc.gnu.org
Subject: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
Date: Thu, 26 Sep 2002 08:26:00 -0000	[thread overview]
Message-ID: <200209261523.g8QFNEXE097485@ork.gte.com> (raw)


>Number:         8055
>Category:       preprocessor
>Synopsis:       PATCH: CPPO dies with SIG11 when building FreeBSD kernel
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          ice-on-legal-code
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 26 08:26:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Alexander N. Kabaev
>Release:        3.2.1 [FreeBSD] 20020916 (prerelease)
>Organization:
>Environment:

System: FreeBSD kanpc.gte.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Mon Sep 16 10:44:41EDT 2002 root@kanpc.gte.com:/usr/obj/usr/src/sys/KANPC  i386
GCC 3.2.1 configured as system compiler

As well as:
System: FreeBSD ork.gte.com 4.7-PRERELEASE FreeBSD 4.7-PRERELEASE #0: Mon Sep 16 11:16:37 EDT 2002 root@ork.gte.com:/usr/src/sys/compile/KAN i386

GCC 3.2.1 built from ports:
host: i386-portbld-freebsd4.7
build: i386-portbld-freebsd4.7
target: i386-portbld-freebsd4.7
configured with: ./..//gcc-20020902/configure --disable-nls --with-gnu-as --with-gnu-ld --with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd4.7/3.2.1/include/g++-v3 --with-system-zlib --includedir=/usr/local/lib/gcc-lib/i386-portbld-freebsd4.7/3.2.1/include/Java --disable-libgcj --disable-shared --prefix=/usr/local i386-portbld-freebsd4.7
>Description:
	Preprocessor CPP0 dumps core when used to create dependencies list 
	while building the FreeBSD kernel. The reason is the bug in gcc/cppmacro.cpp
	in function stringify_arg. If pfile->u_buff buffer is completely filled
	when the function is called (i.e.
	BUFF_FRONT (pfile->u_buff) == BUFF_LIMIT (pfile->u_buff) ), and the
        macro_arg passed to it as a second parameter has no tokens, that is
	arg->count is 0, then stringify_buffer will happily advance the
        BUFF_FRONT(pfile->u_buff) pointer past the BUFF_LIMIT (pfile->u_buff) 
	values, making comparisons like 
          (size_t) (BUFF_LIMIT (pfile->u_buff) - dest) < len
        useless. CPP0 will dump core shortly afterwards trying strchr/strcpy
	a string which it thinks is about 4G in size.

>How-To-Repeat:
	The test case is not exactly trivial to produce. The stringify_arg
	function should be called with an empty argument and completely
	filled buffer. The layout of system header files happend to 
	trigger exectly this condition.
>Fix:
	The patch below takes care of the problem.

Index: contrib/gcc/cppmacro.c
===================================================================
RCS file: /usr/ncvs/src/contrib/gcc/cppmacro.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 cppmacro.c
--- contrib/gcc/cppmacro.c	1 Sep 2002 20:37:29 -0000	1.1.1.4
+++ contrib/gcc/cppmacro.c	24 Sep 2002 15:40:54 -0000
@@ -349,6 +349,12 @@
 
   /* Commit the memory, including NUL, and return the token.  */
   len = dest - BUFF_FRONT (pfile->u_buff);
+  if ((size_t) (BUFF_LIMIT (pfile->u_buff) - dest) < 1)
+    {
+      size_t len_so_far = dest - BUFF_FRONT (pfile->u_buff);
+      _cpp_extend_buff (pfile, &pfile->u_buff, 1);
+      dest = BUFF_FRONT (pfile->u_buff) + len_so_far;
+    }
   BUFF_FRONT (pfile->u_buff) = dest + 1;
   return new_string_token (pfile, dest - len, len);
 }
>Release-Note:
>Audit-Trail:
>Unformatted:


             reply	other threads:[~2002-09-26 15:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-26  8:26 ak03 [this message]
2002-09-27 12:56 Zack Weinberg
2002-09-27 13:16 Alexander Kabaev
2002-09-27 13:56 Mark Mitchell
2002-09-27 15:16 Zack Weinberg
2002-09-27 15:56 Mark Mitchell
2002-10-04 11:46 Neil Booth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200209261523.g8QFNEXE097485@ork.gte.com \
    --to=ak03@gte.com \
    --cc=gcc-gnats@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).