Project

General

Profile

Actions

Bug #17843

open

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) about 2 months ago. Updated about 2 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:103680]

Description

following tutorial

https://www.youtube.com/watch?v=nlKIJfv50U0

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
Rails 6.1.3.1

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

https://github.com/rails/rails/issues/42110


Files

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) about 2 months 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: https://ask.csdn.net/questions/6437692, 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) about 2 months 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
 #endif

-#if 0
+#if 1
+# define fill_random_bytes_syscall(seed, size, need_secure) -1
 #elif defined MAC_OS_X_VERSION_10_7 && MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_7
 #include <Security/Security.h>

Updated by alanwu (Alan Wu) about 2 months 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) about 2 months ago

The latest version of Xcode (12.5 beta) seems to support macOS 10.9 or later: https://developer.apple.com/support/xcode/

Updated by alanwu (Alan Wu) about 2 months 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.

Actions

Also available in: Atom PDF