Bug #17843


Ruby on Rails error[BUG] Segmentation fault at 0x0000000000000110 ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin15] (#42110)

Added by nayaronfire (kk nayar) over 1 year ago. Updated 4 months ago.

Target version:


following tutorial

On this command
$ rails g scaffold Survey name:text laptop:binary os:text
the following error was generated with the following instruction

[BUG] Segmentation fault at 0x0000000000000110
ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin15]
-- Crash Report log information --------------------------------------------
See Crash Report log file under the one of following:
* ~/Library/Logs/DiagnosticReports
* /Library/Logs/DiagnosticReports
for more details.
Don't forget to include the above Crash Report log file in bug reports.
Expected behavior
should have created a scaffold with the above three fields which would facilitate migrating to db after this

Actual behavior
got the above error
ruby crash report_2021-04-30-194015.pdf

System configuration

ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin15]

I am using OS X EL Capitan 10.11.6

I filed a bug in rails. They replied stating it is a ruby error


ruby crash report_2021-04-30-194015.pdf (48.8 KB) ruby crash report_2021-04-30-194015.pdf nayaronfire (kk nayar), 05/01/2021 08:02 AM

Updated by xtkoba (Tee KOBAYASHI) over 1 year ago

The stack trace shows that the crash occurred at:

libdispatch.dylib(_dispatch_queue_wakeup_with_qos_slow+126) [0x00007fff90ff9b06]
libcorecrypto.dylib(ccrng_CommonCrypto_generate+309) [0x00007fff9e03bddc]
libruby.3.0.dylib(ruby_fill_random_bytes+58) [0x0000000101b5b58a]

I googled some symbol names appeared above and found a similar crash:, but the answer in that page might not be very helpful for us as in our case SecRandomCopyBytes is explicitly called at random.c:485.

Updated by xtkoba (Tee KOBAYASHI) over 1 year ago

I wonder if the problem disappears by backporting 4ea96f1d4f8a50c204c4367c994cdbf12cd97b64 which modifies fill_random_bytes_syscall so that it calls CCRandomGenerateBytes instead for newer environments (probably for macOS >= 10.10).

A quicker workaround would be to apply the following patch to avoid calling SecRandomCopyBytes.

--- a/random.c
+++ b/random.c
@@ -475,7 +475,8 @@
 # define HAVE_GETRANDOM 1
-#if 0
+#if 1
+# define fill_random_bytes_syscall(seed, size, need_secure) -1
 #include <Security/Security.h>

Updated by alanwu (Alan Wu) over 1 year ago

OS X El Capitan is no longer supported by Apple.
I'm not sure about Ruby's policy for trying to support OSes that the vendor no longer supports.
In any case, I would suggest upgrading to a newer OS to deal with the crash.

Updated by xtkoba (Tee KOBAYASHI) over 1 year ago

The latest version of Xcode (12.5 beta) seems to support macOS 10.9 or later:

Updated by alanwu (Alan Wu) over 1 year ago

Apologies about my misleading statement about support for the OS.
It doesn't seem to be receiving security updates anymore so I had assumed it reached end of life.

Looking at the report, the crash happens after fork.
There was a Ruby crash in the past that happens when calling getaddrinfo() in the fork child.
I sent Apple a bug report and they closed it as a duplicate, so I take it that they agree it's a bug in their system library. All they told me is that the bug I submitted is a duplicate with bug id 43058266 in their internal bug tracking system to which I have no access. They fixed the bug a few OS updates down the line.

Similar to this crash, that crash happens in libdispatch. Anecdotally, it seems that macOS's support for fork without exec isn't great, especially in older versions. I wouldn't be surprised if this is another system library problem.

A possible workaround for the crash might be running bin/spring stop and prefixing the rails g command with DISABLE_SPRING=1 . This should avoid forking the Ruby process and avoid the crash if my theory about this being fork related is correct.

In any case, I still recommend upgrading to a newer OS.

Updated by mame (Yusuke Endoh) 4 months ago

  • Status changed from Open to Closed

I found two bug reports in other projects that have a similar stack trace:

Both are on El Capitan. I guess there is something wrong in openssl or something in El Capitan. Please try a newer version of macOS, and feel free to reopen this issue if it still occurs.


Also available in: Atom PDF