[Bug c++/53510] New: OOM while compile some code

[Bug c++/53510] New: OOM while compile some code

[pinskia at gcc dot gnu.org]

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

             Bug #: 53510
           Summary: OOM while compile some code
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: pinskia@gcc.gnu.org


While reducing PR 53500 for a different ICE on the trunk.  I ran into a case
where it would cause all the memory to be eaten up.

Compile with -std=c++11.  Sorry it is a big testcase but it is hard to reduce
as I have not set the limits yet,

[Bug c++/53510] OOM while compile some code

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-05-28 17:16:03 UTC ---
Created attachment 27514
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27514
Testcase

[Bug middle-end/53510] [4.8 Regression] OOM while compile some code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic, memory-hog
          Component|c++                         |middle-end
   Target Milestone|---                         |4.8.0
            Summary|OOM while compile some code |[4.8 Regression] OOM while
                   |                            |compile some code

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-05-28 17:21:05 UTC ---
#1  0x0000000000f7b7ea in read_line (file=0x18d9b50) at
/home/pinskia/src/local/gcc/gcc/input.c:111
111          memcpy (ptr, string, pos);
(gdb) p pos
$2 = 96889
(gdb) p/x pos
$3 = 0x17a79

So this is the error message which is causing the huge memory usage.

[Bug middle-end/53510] [4.8 Regression] OOM while compile some code

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-05-28 17:28:51 UTC ---
Stupid guess: does it happen with -fno-diagnostics-show-caret too?

[Bug middle-end/53510] [4.8 Regression] OOM while compile some code

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-05-28 17:29:46 UTC ---
(In reply to comment #3)
> Stupid guess: does it happen with -fno-diagnostics-show-caret too?

It does not happen with -fno-diagnostics-show-caret .

[Bug middle-end/53510] [4.8 Regression] OOM while compile some code

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-05-28 17:38:11 UTC ---
Let's ask Manuel to have a look.

[Bug middle-end/53510] [4.8 Regression] OOM while compile some code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-05-29
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-05-29 07:30:28 UTC ---
Created attachment 27515
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27515
gcc48-pr53510.patch

Ugh, that leaks like crazy.  Not only it forgets to free buffers, but also
doubles the size of the allocation (which is fine) but only adds 2 to the
expected allocated block length, so it allocates twice as much for every 2
bytes beyond 200 characters on a line.

[Bug middle-end/53510] [4.8 Regression] OOM while compile some code

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-05-29 07:53:37 UTC ---
(In reply to comment #6)
> Created attachment 27515 [details]
> gcc48-pr53510.patch
> 
> Ugh, that leaks like crazy.  Not only it forgets to free buffers, but also
> doubles the size of the allocation (which is fine) but only adds 2 to the
> expected allocated block length, so it allocates twice as much for every 2
> bytes beyond 200 characters on a line.

You are right. It is very weird what that code is doing. FWIW, I copied the
function from gcov.c:read_line, so I guess that code has the same bug.

[Bug middle-end/53510] [4.8 Regression] OOM while compile some code

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-05-29 11:34:42 UTC ---
Author: jakub
Date: Tue May 29 11:34:38 2012
New Revision: 187952

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187952
Log:
    PR middle-end/53510
    * input.c (read_line): Use XRESIZEVEC instead of XNEWVEC
    to avoid leaking memory.  No need to handle memory allocation
    failure.  Double string_len on each reallocation instead of
    adding 2.
    * gcov.c (read_line): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gcov.c
    trunk/gcc/input.c

[Bug middle-end/53510] [4.8 Regression] OOM while compile some code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-05-31 12:10:09 UTC ---
Fixed.