From: normalperson@...
Date: 2014-11-19T21:28:27+00:00
Subject: [ruby-core:66367] [ruby-trunk - Bug #10460] Segfault instead of	stack level too deep

Issue #10460 has been updated by Eric Wong.


 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.

----------------------------------------
Bug #10460: Segfault instead of stack level too deep
https://bugs.ruby-lang.org/issues/10460#change-50018

* Author: Arne Brasseur
* Status: Open
* Priority: High
* Assignee: Koichi Sasada
* Category: YARV
* Target version: current: 2.2.0
* ruby -v: ruby 2.2.0dev (2014-10-29 trunk 48188) [x86_64-linux]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
The code to trigger this can be found here: https://gist.github.com/mbj/31163a8e712573877268

Also have a look at the comments there. A lot of different people tried it, in some cases it segfaults, in others it doesn't. It seems to have to do with version of gcc or specific CFLAGS. 

I can reproduce the problem for 2.1.3, 2.1.4, and trunk.



-- 
https://bugs.ruby-lang.org/