public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub.kulik at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/107491] New: GccGo stack not resizing on Solaris
Date: Tue, 01 Nov 2022 10:22:01 +0000	[thread overview]
Message-ID: <bug-107491-4@http.gcc.gnu.org/bugzilla/> (raw)

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

            Bug ID: 107491
           Summary: GccGo stack not resizing on Solaris
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: jakub.kulik at oracle dot com
  Target Milestone: ---

Created attachment 53809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53809&action=edit
simple program with recursion that break on Solaris

Question regarding gccgo and stack sizes on Solaris (and other non GNU/Linux
systems).

When I run a code with (not that deep) recursion (example attached) on Solaris,
it segfaults as it overflows the stack. I checked with gdb on both Linux and
Solaris and Linux is calling `__morestack` once in a while and Solaris does
not. IIUIC, __morestack allocates additional stack when compiled with
`-fsplit-stack`, which is "currently only supported on GNU/Linux".

As for my question, is this behavior (segfault after 4MB stack is exhausted)
expected or is there a different stack resize/overflow prevention on non
`-split-stack` platforms that might not be working correctly on Solaris?

This is on Oracle Solaris 11.4 and gccgo shipped with gcc 10.4, 11.3 and 12.1.

(Golang is fine but that is to be expected as they implement all this in a
different way).

             reply	other threads:[~2022-11-01 10:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-01 10:22 jakub.kulik at oracle dot com [this message]
2022-11-01 11:02 ` [Bug go/107491] Gccgo " ebotcazou at gcc dot gnu.org
2022-11-01 11:11 ` jakub.kulik at oracle dot com
2022-11-01 15:42 ` ian at airs dot com
2022-11-02 13:15 ` jakub.kulik at oracle dot com
2022-11-02 16:59 ` ian at airs dot com
2022-11-03 14:38 ` jakub.kulik at oracle dot com
2022-11-03 15:55 ` ian at airs dot com
2022-11-11 10:51 ` jakub.kulik at oracle dot com
2022-11-11 17:34 ` ian at airs dot com
2022-11-21 12:08 ` jakub.kulik at oracle dot com
2022-11-21 12:11 ` jakub.kulik at oracle dot com
2022-11-29 14:44 ` jakub.kulik at oracle dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-107491-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).