* GC stack overflow on mainline
@ 2002-09-10 10:08 Ulrich Weigand
2002-09-10 21:06 ` Geoff Keating
0 siblings, 1 reply; 3+ messages in thread
From: Ulrich Weigand @ 2002-09-10 10:08 UTC (permalink / raw)
To: geoffk; +Cc: gcc
Hello Geoff,
I've just tracked down a cc1 crash when compiling the GB18030 iconv
converter from glibc on s390x-ibm-linux to a stack overflow inside
the garbage collection machinery.
The problem is that the source file contains a statically initialized
array with a huge initializer list (several 10000 entries). This gets
parsed into a tree with correspondingly large recursion along the
tree->chain field, causing a correspondingly deep recursion of the
gt_ggc_mx_lang_tree_node function when marking that tree.
As (caused in part by the s390x ABI) every call frame takes about
200 bytes of stack, this causes the default Linux stack (8 MB)
to overflow. With 16 MB stack the file compiles fine.
I've noticed you have fixed the problem of deep recursion on the
PCH branch. Do you think this fix could be backported to mainline?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: GC stack overflow on mainline
2002-09-10 10:08 GC stack overflow on mainline Ulrich Weigand
@ 2002-09-10 21:06 ` Geoff Keating
2002-09-11 11:06 ` Richard Henderson
0 siblings, 1 reply; 3+ messages in thread
From: Geoff Keating @ 2002-09-10 21:06 UTC (permalink / raw)
To: Ulrich.Weigand; +Cc: gcc
> Importance: Normal
> Sensitivity:
> Cc: gcc@gcc.gnu.org
> From: "Ulrich Weigand" <Ulrich.Weigand@de.ibm.com>
> Date: Tue, 10 Sep 2002 19:08:02 +0200
> X-MIMETrack: Serialize by Router on D12ML028/12/M/IBM(Release 5.0.9a |January 7, 2002) at
> 10/09/2002 19:08:04
> X-OriginalArrivalTime: 10 Sep 2002 17:08:08.0922 (UTC) FILETIME=[A2F3FBA0:01C258EC]
>
> Hello Geoff,
>
> I've just tracked down a cc1 crash when compiling the GB18030 iconv
> converter from glibc on s390x-ibm-linux to a stack overflow inside
> the garbage collection machinery.
>
> The problem is that the source file contains a statically initialized
> array with a huge initializer list (several 10000 entries). This gets
> parsed into a tree with correspondingly large recursion along the
> tree->chain field, causing a correspondingly deep recursion of the
> gt_ggc_mx_lang_tree_node function when marking that tree.
>
> As (caused in part by the s390x ABI) every call frame takes about
> 200 bytes of stack, this causes the default Linux stack (8 MB)
> to overflow. With 16 MB stack the file compiles fine.
>
>
> I've noticed you have fixed the problem of deep recursion on the
> PCH branch. Do you think this fix could be backported to mainline?
It could be. The changes are quite extensive, though.
--
- Geoffrey Keating <geoffk@geoffk.org>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: GC stack overflow on mainline
2002-09-10 21:06 ` Geoff Keating
@ 2002-09-11 11:06 ` Richard Henderson
0 siblings, 0 replies; 3+ messages in thread
From: Richard Henderson @ 2002-09-11 11:06 UTC (permalink / raw)
To: Geoff Keating; +Cc: Ulrich.Weigand, gcc
On Tue, Sep 10, 2002 at 09:06:53PM -0700, Geoff Keating wrote:
> > I've noticed you have fixed the problem of deep recursion on the
> > PCH branch. Do you think this fix could be backported to mainline?
>
> It could be. The changes are quite extensive, though.
Failure to merge that to mainline would be considered a
regression from gcc 3.1 though.
r~
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-09-11 18:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-10 10:08 GC stack overflow on mainline Ulrich Weigand
2002-09-10 21:06 ` Geoff Keating
2002-09-11 11:06 ` Richard Henderson
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).