[#66126] Creation/Conversion methods/functions table for Ruby types — SASADA Koichi <ko1@...>
Hi,
5 messages
2014/11/07
[#66248] [ruby-trunk - Feature #10423] [PATCH] opt_str_lit*: avoid literal string allocations — normalperson@...
Issue #10423 has been updated by Eric Wong.
3 messages
2014/11/13
[#66595] [ruby-trunk - Bug #10557] [Open] Block not given when the argument is a string — bartosz@...
Issue #10557 has been reported by Bartosz Kopinski.
3 messages
2014/11/30
[ruby-core:66366] Re: [ruby-trunk - Bug #10460] Segfault instead of stack level too deep
From:
Eric Wong <normalperson@...>
Date:
2014-11-19 21:26:54 UTC
List:
ruby-core #66366
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.