public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/101997] New: [9 regression] ICE after r9-8665 at gcc/toplev.c:326
@ 2021-08-20 13:26 seurer at gcc dot gnu.org
  2021-08-20 20:40 ` [Bug fortran/101997] " anlauf at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: seurer at gcc dot gnu.org @ 2021-08-20 13:26 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997

            Bug ID: 101997
           Summary: [9 regression] ICE after r9-8665 at gcc/toplev.c:326
           Product: gcc
           Version: 9.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:abfe42c1fb66a534290bd0a808c2d90842ee848b, r9-8665
make  -k check-gcc-fortran RUNTESTFLAGS="dg.exp=gfortran.dg/pr95091.f90"
FAIL: gfortran.dg/pr95091.f90   -O  (internal compiler error)
FAIL: gfortran.dg/pr95091.f90   -O  (test for excess errors)
# of unexpected failures        2


spawn -ignore SIGHUP
/home3/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../gfortran
-B/home3/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../
-B/home3/seurer/gcc/git/build/gcc-9-test/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-9-test/gcc/testsuite/gfortran.dg/pr95091.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O -fsecond-underscore -S -o pr95091.s
*** buffer overflow detected ***:
/home3/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../f951
terminated
f951: internal compiler error: Aborted
0x109133b3 crash_signal
        /home/seurer/gcc/git/gcc-9-test/gcc/toplev.c:326
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
compiler exited with status 1
FAIL: gfortran.dg/pr95091.f90   -O  (internal compiler error)
FAIL: gfortran.dg/pr95091.f90   -O  (test for excess errors)
Excess errors:
*** buffer overflow detected ***:
/home3/seurer/gcc/git/build/gcc-9-test/gcc/testsuite/gfortran/../../f951
terminated
f951: internal compiler error: Aborted
0x109133b3 crash_signal
        /home/seurer/gcc/git/gcc-9-test/gcc/toplev.c:326


commit abfe42c1fb66a534290bd0a808c2d90842ee848b (HEAD, refs/bisect/bad)
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Sun Jun 7 14:47:24 2020 +0200

    PR fortran/95091 - Buffer overflows with submodules and long symbols

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug fortran/101997] [9 regression] ICE after r9-8665 at gcc/toplev.c:326
  2021-08-20 13:26 [Bug fortran/101997] New: [9 regression] ICE after r9-8665 at gcc/toplev.c:326 seurer at gcc dot gnu.org
@ 2021-08-20 20:40 ` anlauf at gcc dot gnu.org
  2021-08-23  8:47 ` rguenth at gcc dot gnu.org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-08-20 20:40 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997

--- Comment #1 from anlauf at gcc dot gnu.org ---
Can you get more details on where the buffer overflow actually occurs?
I cannot reproduce it on x86_64-pc-linux-gnu even running f951 under valgrind.

The original testcase in pr95091 would have ICEd anyway, and
the blamed commit was supposed to fix that.

If we cannot fix the present regression - assuming it is restricted
to 9-only - we could just remove the testcase.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug fortran/101997] [9 regression] ICE after r9-8665 at gcc/toplev.c:326
  2021-08-20 13:26 [Bug fortran/101997] New: [9 regression] ICE after r9-8665 at gcc/toplev.c:326 seurer at gcc dot gnu.org
  2021-08-20 20:40 ` [Bug fortran/101997] " anlauf at gcc dot gnu.org
@ 2021-08-23  8:47 ` rguenth at gcc dot gnu.org
  2021-08-23 20:05 ` anlauf at gcc dot gnu.org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-08-23  8:47 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Target Milestone|---                         |9.5
   Last reconfirmed|                            |2021-08-23
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I can confirm the ICE on x86_64-linux using f951 built with -O0 -g.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000943abd in set_syms_host_assoc (sym=0x3225c70)
    at /home/rguenther/src/gcc-9-branch/gcc/fortran/parse.c:5949
5949    }
(gdb) bt
#0  0x0000000000943abd in set_syms_host_assoc (sym=0x3225c70)
    at /home/rguenther/src/gcc-9-branch/gcc/fortran/parse.c:5949
#1  0x3837363534333231 in ?? ()
#2  0x3635343332313039 in ?? ()
#3  0x003332315f393837 in ?? ()
#4  0x0000000003225f70 in ?? ()
#5  0x0000000003226110 in ?? ()
#6  0x0000000003226330 in ?? ()
#7  0x0000000003269920 in ?? ()
#8  0x0000000003226550 in ?? ()
#9  0x0000000003226770 in ?? ()
#10 0x00007fffffffd950 in ?? ()
#11 0x000000000099ac44 in do_traverse_symtree (

the cherry-pick seems to have patched the "wrong" function,
get_unique_hashed_string instead of get_unique_type_string which is mentioned
by the ChangeLog but not touched.  get_unique_type_string looks still broken
in this respect, and we run into

Breakpoint 5, get_unique_type_string (string=0x7fffffffd610 "@\302\031\003", 
    derived=0x320d8a0)
    at /home/rguenther/src/gcc-9-branch/gcc/fortran/class.c:483
492         sprintf (string, "%s_%s", derived->ns->proc_name->name, dt_name);
(gdb) ptype dt_name
type = char [64]
(gdb) p (int)strlen (derived->ns->proc_name->name)
$3 = 63
(gdb) p (int)strlen (dt_name)
$4 = 63

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug fortran/101997] [9 regression] ICE after r9-8665 at gcc/toplev.c:326
  2021-08-20 13:26 [Bug fortran/101997] New: [9 regression] ICE after r9-8665 at gcc/toplev.c:326 seurer at gcc dot gnu.org
  2021-08-20 20:40 ` [Bug fortran/101997] " anlauf at gcc dot gnu.org
  2021-08-23  8:47 ` rguenth at gcc dot gnu.org
@ 2021-08-23 20:05 ` anlauf at gcc dot gnu.org
  2021-08-26 19:55 ` anlauf at gcc dot gnu.org
  2022-05-27  9:09 ` rguenth at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-08-23 20:05 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 51348
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51348&action=edit
Partial backport of commit ac932bfcd21e9523fa2b880ae8138aef79da7f54

It's not that the cherry-pick went wrong.

I looked into my notes and saw that I did not backport to 9-branch some patches
that seemed require additional work.  In particular I did not backport the fix
for PR95687, as the related testcase would still ICE due to other missing
stuff.

I have isolated the part of r11-1568 that should handle the dynamic string
length recommended for handling these issues, but I am not 100% sure whether
this is sufficient.
I removed the testcase part of that patch, as even that would still ICE on
x86_64-pc-linux-gnu because of missing other backports.

Alternatively one could temporarily (in the sense of 9-only) use enlarged
static buffers, just to fix the present ICE.

Comments?

@Richi: is there a simple way to compile only the gcc/fortran subdirectory
using specific CFLAGS without having to recompile anything else?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug fortran/101997] [9 regression] ICE after r9-8665 at gcc/toplev.c:326
  2021-08-20 13:26 [Bug fortran/101997] New: [9 regression] ICE after r9-8665 at gcc/toplev.c:326 seurer at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2021-08-23 20:05 ` anlauf at gcc dot gnu.org
@ 2021-08-26 19:55 ` anlauf at gcc dot gnu.org
  2022-05-27  9:09 ` rguenth at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: anlauf at gcc dot gnu.org @ 2021-08-26 19:55 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997

--- Comment #4 from anlauf at gcc dot gnu.org ---
I have run the testcase under the debugger and the longest arguments to
sprintf I have found is

"m2345678901234567890123456789012345678901234567890123456789_123.n2345678901234567890123456789012345678901234567890123456789_123"

(gdb) p (int)strlen(derived->ns->proc_name->name)
$45 = 127

which is 2*GFC_MAX_SYMBOL_LEN+1, and I also do not see how dt_name would
overflow.  (GFC_MAX_SYMBOL_LEN is 63).

I've tentatively increased the buffers in question and run again under gdb
but did not see that the checked string length in get_unique_hashed_string
or gfc_hash_value would change anything.

Here's the simple modification I tried:

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 1a5bcfae3c0..e794a762d33 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -479,7 +479,7 @@ gfc_class_initializer (gfc_typespec *ts, gfc_expr
*init_expr)
 static void
 get_unique_type_string (char *string, gfc_symbol *derived)
 {
-  char dt_name[GFC_MAX_SYMBOL_LEN+1];
+  char dt_name[2*(GFC_MAX_SYMBOL_LEN+1)];
   if (derived->attr.unlimited_polymorphic)
     strcpy (dt_name, "STAR");
   else
@@ -502,7 +502,7 @@ static void
 get_unique_hashed_string (char *string, gfc_symbol *derived)
 {
   /* Provide sufficient space to hold "symbol.symbol_symbol".  */
-  char tmp[3*GFC_MAX_SYMBOL_LEN+3];
+  char tmp[4*(GFC_MAX_SYMBOL_LEN+1)];
   get_unique_type_string (&tmp[0], derived);
   size_t len = strnlen (tmp, sizeof (tmp));
   gcc_assert (len < sizeof (tmp));
@@ -527,7 +527,7 @@ gfc_hash_value (gfc_symbol *sym)
 {
   unsigned int hash = 0;
   /* Provide sufficient space to hold "symbol.symbol_symbol".  */
-  char c[3*GFC_MAX_SYMBOL_LEN+3];
+  char c[4*(GFC_MAX_SYMBOL_LEN+1)];
   int i, len;

   get_unique_type_string (&c[0], sym);

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug fortran/101997] [9 regression] ICE after r9-8665 at gcc/toplev.c:326
  2021-08-20 13:26 [Bug fortran/101997] New: [9 regression] ICE after r9-8665 at gcc/toplev.c:326 seurer at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2021-08-26 19:55 ` anlauf at gcc dot gnu.org
@ 2022-05-27  9:09 ` rguenth at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-05-27  9:09 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101997

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|NEW                         |RESOLVED

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Branch is closed.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-05-27  9:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-20 13:26 [Bug fortran/101997] New: [9 regression] ICE after r9-8665 at gcc/toplev.c:326 seurer at gcc dot gnu.org
2021-08-20 20:40 ` [Bug fortran/101997] " anlauf at gcc dot gnu.org
2021-08-23  8:47 ` rguenth at gcc dot gnu.org
2021-08-23 20:05 ` anlauf at gcc dot gnu.org
2021-08-26 19:55 ` anlauf at gcc dot gnu.org
2022-05-27  9:09 ` rguenth at gcc dot gnu.org

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).