Newest gcc memory leak on gdb (heads up, only)

Newest gcc memory leak on gdb (heads up, only)

[Donn Terry]

Just in case someone else is also looking at this....

Sometime between 5/13 and yesterday (5/28) evening (4:30P Pacific), a
change was made to
either gdb or gcc such that attempting to compile gdb/p-typeprint.c
causes a bad memory leak (at least for me).  (After 30 seconds it was at
300M
and finally it grows enough to crash.)

I'm looking at this now to figure out what's going on.  If anyone else
is looking into this, please let me know.

Donn

Re: Newest gcc memory leak on gdb (heads up, only)

[Andreas Schwab]

"Donn Terry" <donnte@microsoft.com> writes:

|> Just in case someone else is also looking at this....
|> 
|> Sometime between 5/13 and yesterday (5/28) evening (4:30P Pacific), a
|> change was made to
|> either gdb or gcc such that attempting to compile gdb/p-typeprint.c
|> causes a bad memory leak (at least for me).  (After 30 seconds it was at
|> 300M
|> and finally it grows enough to crash.)

I'm seeing a similar leak when bootstrapping on ia64 with Ada enabled.
The stage1 compiler is dying while compiling ada/exp_ch11.adb.  The
problem started yesterday, the last working CVS was from Tue May 28
08:06:25 UTC 2002.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Newest gcc memory leak on gdb (heads up, only)

[law]

In message <jey9e1yasz.fsf@sykes.suse.de>, Andreas Schwab writes:
 > "Donn Terry" <donnte@microsoft.com> writes:
 > 
 > |> Just in case someone else is also looking at this....
 > |> 
 > |> Sometime between 5/13 and yesterday (5/28) evening (4:30P Pacific), a
 > |> change was made to
 > |> either gdb or gcc such that attempting to compile gdb/p-typeprint.c
 > |> causes a bad memory leak (at least for me).  (After 30 seconds it was at
 > |> 300M
 > |> and finally it grows enough to crash.)
 > 
 > I'm seeing a similar leak when bootstrapping on ia64 with Ada enabled.
 > The stage1 compiler is dying while compiling ada/exp_ch11.adb.  The
 > problem started yesterday, the last working CVS was from Tue May 28
 > 08:06:25 UTC 2002.
The regression tester is also coughing.

I recommend we first get the regression tester back into a known good
state, then look and see if the "memory leak" problems are still around.

Right now the regression tester is failing to build mips-elf in a way that
could be related to my changes from yesterday.  Clearly I'm in the process
of trying to build mips-elf myself so that I can investigate. :-)

jeff

Mainline does not bootstrap for more than a week (Re: Newest gcc memory leak on gdb (heads up, only))

[Andreas Schwab]

law@redhat.com writes:

|> In message <jey9e1yasz.fsf@sykes.suse.de>, Andreas Schwab writes:
|>  > "Donn Terry" <donnte@microsoft.com> writes:
|>  > 
|>  > |> Just in case someone else is also looking at this....
|>  > |> 
|>  > |> Sometime between 5/13 and yesterday (5/28) evening (4:30P Pacific), a
|>  > |> change was made to
|>  > |> either gdb or gcc such that attempting to compile gdb/p-typeprint.c
|>  > |> causes a bad memory leak (at least for me).  (After 30 seconds it was at
|>  > |> 300M
|>  > |> and finally it grows enough to crash.)
|>  > 
|>  > I'm seeing a similar leak when bootstrapping on ia64 with Ada enabled.
|>  > The stage1 compiler is dying while compiling ada/exp_ch11.adb.  The
|>  > problem started yesterday, the last working CVS was from Tue May 28
|>  > 08:06:25 UTC 2002.
|> The regression tester is also coughing.
|> 
|> I recommend we first get the regression tester back into a known good
|> state, then look and see if the "memory leak" problems are still around.

The memory leak is still present.  Has anyone an idea how to fix that?
Bootstrap is broken for more than a week now!

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Mainline does not bootstrap for more than a week (Re: Newest gcc memory leak on gdb (heads up, only))

[Andreas Schwab]

Andreas Schwab <schwab@suse.de> writes:

|> law@redhat.com writes:
|> 
|> |> In message <jey9e1yasz.fsf@sykes.suse.de>, Andreas Schwab writes:
|> |>  > "Donn Terry" <donnte@microsoft.com> writes:
|> |>  > 
|> |>  > |> Just in case someone else is also looking at this....
|> |>  > |> 
|> |>  > |> Sometime between 5/13 and yesterday (5/28) evening (4:30P Pacific), a
|> |>  > |> change was made to
|> |>  > |> either gdb or gcc such that attempting to compile gdb/p-typeprint.c
|> |>  > |> causes a bad memory leak (at least for me).  (After 30 seconds it was at
|> |>  > |> 300M
|> |>  > |> and finally it grows enough to crash.)
|> |>  > 
|> |>  > I'm seeing a similar leak when bootstrapping on ia64 with Ada enabled.
|> |>  > The stage1 compiler is dying while compiling ada/exp_ch11.adb.  The
|> |>  > problem started yesterday, the last working CVS was from Tue May 28
|> |>  > 08:06:25 UTC 2002.
|> |> The regression tester is also coughing.
|> |> 
|> |> I recommend we first get the regression tester back into a known good
|> |> state, then look and see if the "memory leak" problems are still around.
|> 
|> The memory leak is still present.  Has anyone an idea how to fix that?
|> Bootstrap is broken for more than a week now!

Filed as PR bootstrap/6929.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Mainline does not bootstrap for more than a week (Re: Newest gcc memory leak on gdb (heads up, only))

[law]

 In message <jewutfrseg.fsf@sykes.suse.de>, Andreas Schwab writes:
 > |> The memory leak is still present.  Has anyone an idea how to fix that?
 > |> Bootstrap is broken for more than a week now!
 > 
 > Filed as PR bootstrap/6929.
Bummer (memory leak still present).  Thanks for verifying and opening the
bug report.

jeff