Reproducable SIGSEGV (char ************* etc.)

[gst]

Binary package hint: gcc-4.1

When you declare a variable which uses the *-operator a _lot_ of times, this causes gcc (the cc1 binary) to segfault. This problem may actually be exploitable.

Example: char ********************* (and so on with about 170k of further '*' characters. the exact number differs if memory randomization is used.).

An example source code is available at: http://virtual.sysfrog.org/~gst/gccbug/foo.c

Example session:
gst@pico:~$ gdb -q /usr/lib/gcc/i486-linux-gnu/4.1/cc1
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) r foo.c
Starting program: /usr/lib/gcc/i486-linux-gnu/4.1/cc1 foo.c
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
 main
Program received signal SIGSEGV, Segmentation fault.
0x084542bc in ?? ()

[Rwxr-xr-x (rwxr-xr-x)]

$ perl -wle 'print "int", "*" x 999999, "p;"' >try.c && gcc try.c
gcc: Internal error: Segmentation fault (program cc1)
...

$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.1.1-r3/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --enable-java-awt=gtk --enable-languages=c,c++,java,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.1 (Gentoo 4.1.1-r3)

gcc-4.3-20070427 seems to have the same problem.
3.4.6 works fine, but after increasing the number of *'s to 99999999 it says:
cc1: out of memory allocating 1677721600 bytes after a total of 845819904 bytes

So this problem seems to be new in gcc4.

[Rguenth (rguenth)]

you must be kidding.

[Fang-a (fang-a)]

adding to personal favorite list :)

[Bangerth (bangerth)]

(In reply to comment #0)
> $ perl -wle 'print "int", "*" x 999999, "p;"' >try.c && gcc try.c
> gcc: Internal error: Segmentation fault (program cc1)

Yo, dude, that would take a seriously long program to even initialize
that pointer :-)

But seriously, while I do think that we should strive to compile even
programs that are "weird" or "unusual" in their requirements on the
compiler, I think that this one goes a little overboard. I would,
however, be interested to hear how many levels of pointers gcc
actually *can* compile. I would imagine it's at least a few
hundred, maybe thousand. Maybe you could try to figure out?

Best
  Wolfgang

[Joseph-codesourcery (joseph-codesourcery)]

Subject: Re: gcc segfaults on very long pointer chains

On Fri, 4 May 2007, bangerth at dealii dot org wrote:

> But seriously, while I do think that we should strive to compile even
> programs that are "weird" or "unusual" in their requirements on the
> compiler, I think that this one goes a little overboard. I would,
> however, be interested to hear how many levels of pointers gcc
> actually *can* compile. I would imagine it's at least a few
> hundred, maybe thousand. Maybe you could try to figure out?

That would depend on your stack limit (so the question would really be,
for each extra MB of stack limit how many more levels can it compile)?
For such extreme programs I think it's reasonable to expect users to
increase their stack limit when running the compiler.

Although in this case, it would be reasonably straightforward to make
c_parser_declarator iterative (with an internal linked list on the parser
obstack) rather than recursive - if that were actually of use in compiling
real code with real stack limits.

[gst (gstarnberger)]

Add-on: This problem occurs before the whole file is parsed. Therefore, the part of the file after the '*'-sequence does not need to be valid C-code anymore.

[Dominique Pellé (dominique-pelle)]

I can also reproduce it with Ubuntu Gutsy using the attached file from bug submitter.
The #include <stdlio.h> in foo.c test case is not necessary. It can be removed (so
test case does not depened on external header file) and it still cause a crash of gcc:

$ gcc --version
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc foo.c
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
<URL:file:///usr/share/doc/gcc-4.1/README.Bugs>.

[Dominique Pellé (dominique-pelle)]

I can also reproduce using the newer gcc-4.2.1 (using Ubuntu's package for gcc-4.2).

$ gcc -V 4.2 --version
i486-linux-gnu-gcc-4.2 (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -V 4.2 foo.c
i486-linux-gnu-gcc-4.2: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
<URL:file:///usr/share/doc/gcc-4.2/README.Bugs>.

I will submit the bug as described in http://gcc.gnu.org/bugs.html

[Dominique Pellé (dominique-pelle)]

I've just opened a bug in gcc bugzilla database for this. See:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34308

[Pinskia (pinskia)]

*** Bug 34308 has been marked as a duplicate of this bug. ***

[Matthias Klose (doko)]

closing as won't fix as upstream did.