Ruby on Rails App crashes on request on M1 Mac

294 views Asked by At

I am working on an older Ruby on Rails app. It is running on Ruby 2.7.8 and Rails 6.1.4. I am working on an M1 MacBook Pro. I have installed Ruby using rbenv initially, then removed that and used rvm.

Whenever I attempt to run the app, it starts up fine, but on the first HTTP request to the server - it crashes the worker thread and respawns it. Looking in the puma log I see:

ruby 2.7.8p225 (2023-03-30 revision 1f4d455848) [x86_64-darwin23]

-- 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.

-- Control frame information -----------------------------------------------
c:0009 p:---- s:0040 e:000039 CFUNC  :sleep
c:0008 p:---- s:0037 e:000036 CFUNC  :wait
c:0007 p:0033 s:0031 e:000030 BLOCK  app/vendor/cache/ruby/2.7.0/gems/timeout-0.4.0/lib/timeout.rb:110 [FINISH]
c:0006 p:---- s:0028 e:000027 CFUNC  :synchronize
c:0005 p:0092 s:0024 e:000023 BLOCK  app/vendor/cache/ruby/2.7.0/gems/timeout-0.4.0/lib/timeout.rb:108
c:0004 p:0007 s:0017 e:000016 BLOCK  app/vendor/cache/ruby/2.7.0/gems/newrelic_rpm-9.5.0/lib/new_relic/age
c:0003 p:0009 s:0014 e:000013 METHOD app/vendor/cache/ruby/2.7.0/gems/newrelic_rpm-9.5.0/lib/new_relic/age
c:0002 p:0176 s:0008 e:000007 BLOCK  app/vendor/cache/ruby/2.7.0/gems/newrelic_rpm-9.5.0/lib/new_relic/age [FINISH]
c:0001 p:---- s:0003 e:000002 (none) [FINISH]

-- Ruby level backtrace information ----------------------------------------
app/vendor/cache/ruby/2.7.0/gems/newrelic_rpm-9.5.0/lib/new_relic/agent/tracer.rb:434:in `block in thread_block_with_current_transaction'
app/vendor/cache/ruby/2.7.0/gems/newrelic_rpm-9.5.0/lib/new_relic/agent/tracer.rb:357:in `capture_segment_error'
app/vendor/cache/ruby/2.7.0/gems/newrelic_rpm-9.5.0/lib/new_relic/agent/tracer.rb:435:in `block (2 levels) in thread_block_with_current_transaction'
app/vendor/cache/ruby/2.7.0/gems/timeout-0.4.0/lib/timeout.rb:108:in `block in create_timeout_thread'
app/vendor/cache/ruby/2.7.0/gems/timeout-0.4.0/lib/timeout.rb:108:in `synchronize'
app/vendor/cache/ruby/2.7.0/gems/timeout-0.4.0/lib/timeout.rb:110:in `block (2 levels) in create_timeout_thread'
app/vendor/cache/ruby/2.7.0/gems/timeout-0.4.0/lib/timeout.rb:110:in `wait'
app/vendor/cache/ruby/2.7.0/gems/timeout-0.4.0/lib/timeout.rb:110:in `sleep'

There is a lot more logged, and a MacOS crash report is produced:

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               ruby [1319]
Path:                  /Users/USER/*/ruby
Identifier:            ruby
Version:               ???
Code Type:             X86-64 (Translated)
Parent Process:        ruby [992]
Responsible:           Terminal [4449]
User ID:               501

Date/Time:             2023-10-18 19:36:29.3647 -0400
OS Version:            macOS 14.0 (23A344)
Report Version:        12
Anonymous UUID:        C4F7558A-CFBD-4604-6BD6-546A0CE3419A


Time Awake Since Boot: 4200 seconds

System Integrity Protection: enabled

Notes:
PC register does not match crashing frame (0x0 vs 0x7FF897412A78)

Crashed Thread:        6  tracer.rb:426

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x0000000108dc0acc
Exception Codes:       0x0000000000000002, 0x0000000108dc0acc

Termination Reason:    Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process:   ruby [1319]

I've tried just about every thing I've found online, including using older OpenSSL versions when building Ruby. I have no idea why Ruby crashes constantly but it seems to only happen when I run the app and make an HTTP request.

Since Ruby is dying entirely, I get nothing in the console output. I do get the above in puma log and the crash report in the OS. But nothing that hints at this being a code issue.

I suspect it's a x86_64 vs arm issue. I've tried using all Apple Silicon libraries, with no success and all x86_64 as well with the same result. Has anyone run into this and if so how did you fix it?


EDIT: I completely reset my Mac (it was over 3 years since I did - it was due) - and followed the instructions linked below. No dice. I get almost exactly the same errors:

Thread 5 Crashed:: thread_pool.rb*
0   libsystem_kernel.dylib                 0x18707311c __pthread_kill + 8
1   libsystem_pthread.dylib                0x1870aacc0 pthread_kill + 288
2   libsystem_c.dylib                      0x186fbaa50 abort + 180
3   libruby.2.7.dylib                      0x1016f04bc die + 12
4   libruby.2.7.dylib                      0x1016f0600 rb_bug_for_fatal_signal + 324
5   libruby.2.7.dylib                      0x1017e4ef0 sigsegv + 96
6   libsystem_platform.dylib               0x1870d9a24 _sigtramp + 56
7   libsystem_trace.dylib                  0x186e0f220 _os_log_preferences_refresh + 40
8   libsystem_trace.dylib                  0x186e0fc9c os_log_type_enabled + 712
9   CoreFoundation                         0x18713a650 -[CFPrefsSearchListSource alreadylocked_copyValueForKey:] + 204
10  CoreFoundation                         0x18713a564 -[CFPrefsSource copyValueForKey:] + 52
11  CoreFoundation                         0x18713a518 __76-[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:]_block_invoke + 32
12  CoreFoundation                         0x187133b64 __108-[_CFXPreferences(SearchListAdditions) withSearchListForIdentifier:container:cloudConfigurationURL:perform:]_block_invoke + 376
13  CoreFoundation                         0x1872b6710 -[_CFXPreferences withSearchListForIdentifier:container:cloudConfigurationURL:perform:] + 384
14  CoreFoundation                         0x187133440 -[_CFXPreferences copyAppValueForKey:identifier:container:configurationURL:] + 156
15  CoreFoundation                         0x187133368 _CFPreferencesCopyAppValueWithContainerAndConfiguration + 112
16  Heimdal                                0x1953793e4 init_context_from_config_file + 2932
17  Heimdal                                0x19535d82c krb5_set_config_files + 440
18  Heimdal                                0x19535d0ac krb5_init_context_flags + 348
19  Heimdal                                0x19535cf44 krb5_init_context + 32
20  Kerberos                               0x1978a0334 mshim_ctx + 64
21  Kerberos                               0x19789e76c context_new_ccache_iterator + 92
22  libkrb5.3.3.dylib                      0x1031f05b4 api_macos_ptcursor_next + 220
23  libkrb5.3.3.dylib                      0x1031ed8bc krb5_cccol_cursor_next + 80
24  libkrb5.3.3.dylib                      0x1031edb98 krb5_cccol_have_content + 92
25  libgssapi_krb5.2.2.dylib               0x1014c9a2c acquire_cred_context + 1740
26  libgssapi_krb5.2.2.dylib               0x1014c92e8 acquire_cred_from + 688
27  libgssapi_krb5.2.2.dylib               0x1014bb340 gss_add_cred_from + 628
28  libgssapi_krb5.2.2.dylib               0x1014baf84 gss_acquire_cred_from + 400
29  libgssapi_krb5.2.2.dylib               0x1014bade8 gss_acquire_cred + 36
30  libpq.5.14.dylib                       0x10147c0d4 pg_GSS_have_cred_cache + 60
31  libpq.5.14.dylib                       0x10146ae6c PQconnectPoll + 4468
32  libpq.5.14.dylib                       0x1014686d0 connectDBComplete + 276
33  libpq.5.14.dylib                       0x10146883c PQconnectdb + 44
34  pg_ext.bundle                          0x1013d655c gvl_PQconnectdb_skeleton + 24 (gvl_wrappers.c:13)
35  libruby.2.7.dylib                      0x101815788 rb_nogvl + 216
36  pg_ext.bundle                          0x1013d6534 gvl_PQconnectdb + 40 (gvl_wrappers.c:14)
37  pg_ext.bundle                          0x1013db5c8 pgconn_init + 128 (pg_connection.c:276)
38  libruby.2.7.dylib                      0x10184d258 vm_call0_body + 1340
39  libruby.2.7.dylib                      0x10184e74c rb_call + 456
40  libruby.2.7.dylib                      0x10184e9d0 rb_funcallv_kw + 108
41  libruby.2.7.dylib                      0x10177b344 rb_class_s_new + 64
42  libruby.2.7.dylib                      0x101857f08 vm_call_cfunc + 280
43  libruby.2.7.dylib                      0x101843910 vm_exec_core + 10404
44  libruby.2.7.dylib                      0x101854aa4 rb_vm_exec + 1892
45  libruby.2.7.dylib                      0x10186083c send_internal + 1316
46  libruby.2.7.dylib                      0x101851a00 rb_f_public_send + 100
47  libruby.2.7.dylib                      0x101857f08 vm_call_cfunc + 280
48  libruby.2.7.dylib                      0x101843910 vm_exec_core + 10404
49  libruby.2.7.dylib                      0x101854aa4 rb_vm_exec + 1892
50  libruby.2.7.dylib                      0x10184effc rb_yield + 184
51  libruby.2.7.dylib                      0x1016f81cc rb_ensure + 204
52  libruby.2.7.dylib                      0x101857f08 vm_call_cfunc + 280
53  libruby.2.7.dylib                      0x1018434d0 vm_exec_core + 9316
54  libruby.2.7.dylib                      0x101854aa4 rb_vm_exec + 1892
55  libruby.2.7.dylib                      0x10184d714 rb_vm_call_kw + 180
56  libruby.2.7.dylib                      0x10185d820 vm_yield_with_cfunc + 220
57  libruby.2.7.dylib                      0x10185d054 vm_invoke_block + 612
58  libruby.2.7.dylib                      0x101843910 vm_exec_core + 10404
59  libruby.2.7.dylib                      0x101854aa4 rb_vm_exec + 1892
60  libruby.2.7.dylib                      0x10181d080 thread_do_start + 768
61  libruby.2.7.dylib                      0x10181cb1c thread_start_func_2 + 564
62  libruby.2.7.dylib                      0x10181c778 thread_start_func_1 + 292
63  libsystem_pthread.dylib                0x1870ab034 _pthread_start + 136
64  libsystem_pthread.dylib                0x1870a5e3c thread_start + 8

EDIT 2: Amazing. Stuff like this is why folks aren't flocking to the Ruby ecosystem anymore IMO. The fix ended up being specific to PostgreSQL. Specifically, adding this option to the database connection in database.yml:

  gssencmode: "disable"

Amazingly, the app worked fine after that and booted properly. I am able to make web requests now.

0

There are 0 answers