public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
@ 2002-10-04 11:46 Neil Booth
0 siblings, 0 replies; 7+ messages in thread
From: Neil Booth @ 2002-10-04 11:46 UTC (permalink / raw)
To: zack; +Cc: gcc-prs
The following reply was made to PR preprocessor/8055; it has been noted by GNATS.
From: Neil Booth <neil@daikokuya.co.uk>
To: Zack Weinberg <zack@codesourcery.com>
Cc: ak03@gte.com, Mark Mitchell <mark@codesourcery.com>,
gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
Date: Fri, 4 Oct 2002 19:42:00 +0100
Zack Weinberg wrote:-
> Thank you for this bug report. I've reproduced the problem, and
> confirm your analysis. I'm going to do a complete bootstrap+test
> cycle on a slight modification of your patch (see below) and will
> apply to mainline if successful.
Thanks Zack. Catching up on 5 figures of email...
Neil.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
@ 2002-09-27 15:56 Mark Mitchell
0 siblings, 0 replies; 7+ messages in thread
From: Mark Mitchell @ 2002-09-27 15:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/8055; it has been noted by GNATS.
From: Mark Mitchell <mark@codesourcery.com>
To: Zack Weinberg <zack@codesourcery.com>
Cc: "ak03@gte.com" <ak03@gte.com>, Neil Booth <neil@daikokuya.co.uk>,
"gcc-gnats@gcc.gnu.org" <gcc-gnats@gcc.gnu.org>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
Date: Fri, 27 Sep 2002 15:45:49 -0700
> I can say that I reproduced the bug under laboratory conditions using
> top of trunk and top of 3.2 (nee 3.1) branch, and that the same
> procedure fails to provoke a bug using the top of the 3.0 branch,
> where the memory allocation code is different.
I think that's good enough. Check it in.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
@ 2002-09-27 15:16 Zack Weinberg
0 siblings, 0 replies; 7+ messages in thread
From: Zack Weinberg @ 2002-09-27 15:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/8055; it has been noted by GNATS.
From: Zack Weinberg <zack@codesourcery.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: "ak03@gte.com" <ak03@gte.com>, Neil Booth <neil@daikokuya.co.uk>,
"gcc-gnats@gcc.gnu.org" <gcc-gnats@gcc.gnu.org>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
Date: Fri, 27 Sep 2002 15:11:28 -0700
On Fri, Sep 27, 2002 at 01:50:20PM -0700, Mark Mitchell wrote:
>
>
> --On Friday, September 27, 2002 12:50:09 PM -0700 Zack Weinberg
> <zack@codesourcery.com> wrote:
>
> >Thank you for this bug report. I've reproduced the problem, and
> >confirm your analysis. I'm going to do a complete bootstrap+test
> >cycle on a slight modification of your patch (see below) and will
> >apply to mainline if successful.
>
> I think we need to figure out if this is a regression before applying
> it to the branch. Just in case. If it is a regression, it's fine.
Reproducing the bug is a bit tricky; I have to instrument the buggy
routine and then adjust the filler text in the test case by hand.
3.0, 3.2 (nee 3.1), and mainline all want different lengths of filler
text.
I can say that I reproduced the bug under laboratory conditions using
top of trunk and top of 3.2 (nee 3.1) branch, and that the same
procedure fails to provoke a bug using the top of the 3.0 branch,
where the memory allocation code is different. I can also say that
2.95, being the last release to use cccp.c, handled stringification
quite differently and is unlikely to have this bug. I haven't managed
to reproduce the bug "in the wild" - i.e. using compilers I didn't
build myself, or without instrumentation and tweaking. However, we
have the original report from the FreeBSD people to say that it does
occur in the wild. Is that good enough to call this a regression?
zw
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
@ 2002-09-27 13:56 Mark Mitchell
0 siblings, 0 replies; 7+ messages in thread
From: Mark Mitchell @ 2002-09-27 13:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/8055; it has been noted by GNATS.
From: Mark Mitchell <mark@codesourcery.com>
To: Zack Weinberg <zack@codesourcery.com>, "ak03@gte.com" <ak03@gte.com>,
Neil Booth <neil@daikokuya.co.uk>
Cc: "gcc-gnats@gcc.gnu.org" <gcc-gnats@gcc.gnu.org>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
Date: Fri, 27 Sep 2002 13:50:20 -0700
--On Friday, September 27, 2002 12:50:09 PM -0700 Zack Weinberg
<zack@codesourcery.com> wrote:
> Thank you for this bug report. I've reproduced the problem, and
> confirm your analysis. I'm going to do a complete bootstrap+test
> cycle on a slight modification of your patch (see below) and will
> apply to mainline if successful.
I think we need to figure out if this is a regression before applying
it to the branch. Just in case. If it is a regression, it's fine.
Thanks,
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
@ 2002-09-27 13:16 Alexander Kabaev
0 siblings, 0 replies; 7+ messages in thread
From: Alexander Kabaev @ 2002-09-27 13:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/8055; it has been noted by GNATS.
From: Alexander Kabaev <ak03@gte.com>
To: Zack Weinberg <zack@codesourcery.com>
Cc: mark@codesourcery.com, neil@daikokuya.co.uk, gcc-gnats@gcc.gnu.org,
gcc-patches@gcc.gnu.org
Subject: Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
Date: Fri, 27 Sep 2002 16:06:46 -0400
Thanks for a prompt reply!
I would really like to see the bug fixed in 3.2.1. The problem is very
repeatable on FreeBSD and is very annoying. At the moment I made a patch
available from my home page, but I really want to keep the number of
local changes at minimum for FreeBSD system compiler.
--
Alexander Kabaev
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
@ 2002-09-27 12:56 Zack Weinberg
0 siblings, 0 replies; 7+ messages in thread
From: Zack Weinberg @ 2002-09-27 12:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR preprocessor/8055; it has been noted by GNATS.
From: Zack Weinberg <zack@codesourcery.com>
To: ak03@gte.com, Mark Mitchell <mark@codesourcery.com>,
Neil Booth <neil@daikokuya.co.uk>
Cc: gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
Date: Fri, 27 Sep 2002 12:50:09 -0700
Thank you for this bug report. I've reproduced the problem, and
confirm your analysis. I'm going to do a complete bootstrap+test
cycle on a slight modification of your patch (see below) and will
apply to mainline if successful.
Mark, is this an acceptable patch for 3.2.1? It's not clear whether
it's a regression from earlier 3.x, but it has been seen in the wild,
and the fix is small, self-contained, and obvious.
zw
* cppmacro.c (stringify_arg): Do not overflow the buffer
with the terminating NUL when the argument to be stringified
has no tokens.
* gcc.dg/cpp/20020927-1.c: New test case.
===================================================================
Index: cppmacro.c
--- cppmacro.c 22 Sep 2002 02:03:17 -0000 1.124
+++ cppmacro.c 27 Sep 2002 19:48:15 -0000
@@ -409,6 +409,12 @@ stringify_arg (pfile, arg)
}
/* Commit the memory, including NUL, and return the token. */
+ 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;
+ }
len = dest - BUFF_FRONT (pfile->u_buff);
BUFF_FRONT (pfile->u_buff) = dest + 1;
return new_string_token (pfile, dest - len, len);
===================================================================
Index: testsuite/gcc.dg/cpp/20020927-1.c
--- testsuite/gcc.dg/cpp/20020927-1.c 1 Jan 1970 00:00:00 -0000
+++ testsuite/gcc.dg/cpp/20020927-1.c 27 Sep 2002 19:47:37 -0000
@@ -0,0 +1,91 @@
+/* Test case for buffer overflow bug in token stringification.
+ See PR preprocessor/8055 for details.
+ Reported by Alexander N. Kabaev <ak03@gte.com>.
+ Test case written by Zack Weinberg <zack@codesourcery.com>. */
+
+/* { dg-do preprocess } */
+
+#define S(x) #x
+
+/* Fill up one internal buffer with data. */
+S(1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 1234567890123456789012345678901234567890123456789012345678901234567890
+ 12345678901234567890123456789012345678901234567890123456789012345)
+
+/* When stringify_arg() was called with an empty macro argument, it would
+ advance the buffer pointer by one but fail to check for running past the
+ end of the buffer. We can only know where the end of the buffer is to
+ within about eight bytes, so do this sixteen times to be sure of hitting
+ it. */
+
+S()
+S()
+S()
+S()
+S()
+S()
+S()
+S()
+S()
+S()
+S()
+S()
+S()
+S()
+S()
+S()
+
+/* Now allocate more memory in the buffer, which should provoke a crash. */
+
+S(abcdefghijklmnopqrstuvwxyz)
+S(abcdefghijklmnopqrstuvwxyz)
^ permalink raw reply [flat|nested] 7+ messages in thread
* preprocessor/8055: CPP0 segfault on FreeBSD + PATCH
@ 2002-09-26 8:26 ak03
0 siblings, 0 replies; 7+ messages in thread
From: ak03 @ 2002-09-26 8:26 UTC (permalink / raw)
To: gcc-gnats
>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:
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-10-04 18:46 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-10-04 11:46 preprocessor/8055: CPP0 segfault on FreeBSD + PATCH Neil Booth
-- strict thread matches above, loose matches on Subject: below --
2002-09-27 15:56 Mark Mitchell
2002-09-27 15:16 Zack Weinberg
2002-09-27 13:56 Mark Mitchell
2002-09-27 13:16 Alexander Kabaev
2002-09-27 12:56 Zack Weinberg
2002-09-26 8:26 ak03
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).