ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: Ruby developers <ruby-core@ruby-lang.org>
Subject: [ruby-core:66366] Re: [ruby-trunk - Bug #10460] Segfault instead of stack level too deep
Date: Wed, 19 Nov 2014 21:26:54 +0000	[thread overview]
Message-ID: <20141119212654.GA31069@dcvr.yhbt.net> (raw)
In-Reply-To: <redmine.journal-50017.20141119211336.43b12b4ecc92d0f1@ruby-lang.org>

arne@arnebrasseur.net wrote:
> Mutant will often generate "broken" code, that's how it works, so
> endless recursion could be the result. It needs to be able to detect
> somehow that things go wrong. A segfault is actually not the biggest
> problem. Mutant forks off workers, so if the worker dies it can assume
> something went wrong. Sometimes the code in this ticket also causes
> Ruby to get stuck in a futex. In that case the worker is "stuck" and
> Mutant becomes unusable.

The freezing is likely caused by the stack overflow corrupting memory
used by a mutex, putting the mutex in an unrecoverable state.
You're better off to detecting lockups in the parent process via
periodic checks.

> > We may increase the size of the guard area; but that costs memory.
> > Right now, on (most) Linux systems, this guard costs 4K (one page)
> > per-thread.
> 
> Could you tell me where in the code I can see this? I would love to
> investigate this more. Thanks!

On GNU/Linux systems, this is done by glibc upon thread creation.

We only set the stack size via pthread_attr_setstacksize in
thread_pthread.c, but we could also call pthread_attr_setguardsize in
the same place.

  reply	other threads:[~2014-11-19 21:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-10460.20141030131734@ruby-lang.org>
2014-10-30 13:17 ` [ruby-core:66023] [ruby-trunk - Bug #10460] [Open] Segfault instead of stack level too deep arne
2014-11-04  9:43 ` [ruby-core:66075] [ruby-trunk - Bug #10460] " arne
2014-11-12  4:17 ` [ruby-core:66219] " a_lamothe
2014-11-18 13:53 ` [ruby-core:66345] " arne
2014-11-19  7:51   ` [ruby-core:66358] " Eric Wong
2014-11-19  7:58 ` [ruby-core:66359] " normalperson
2014-11-19 21:13 ` [ruby-core:66365] " arne
2014-11-19 21:26   ` Eric Wong [this message]
2014-11-19 21:28 ` [ruby-core:66367] " normalperson
2014-11-26 22:33 ` [ruby-core:66497] " andrewm.bpi
2014-11-27 11:23 ` [ruby-core:66520] " ko1
2014-12-03 13:58 ` [ruby-core:66659] " v.ondruch
2014-12-21  1:06 ` [ruby-core:67009] " nobu
2015-02-09 14:17 ` [ruby-core:68074] [Ruby trunk " arne
2015-06-26 10:16 ` [ruby-core:69742] " contact
2019-08-21  3:52 ` [ruby-core:94454] [Ruby master Bug#10460] " merch-redmine

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-list from there: mbox

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

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

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

  git send-email \
    --in-reply-to=20141119212654.GA31069@dcvr.yhbt.net \
    --to=ruby-core@ruby-lang.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).