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,
Created attachment 27514 [details] Testcase
#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.
Stupid guess: does it happen with -fno-diagnostics-show-caret too?
(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 .
Let's ask Manuel to have a look.
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.
(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.
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
Fixed.