Here's the problem: Unable to start an existing Rails project after upgrading to MacOS 10.15.1. The terminal shows this (below) after Rails s and going to localhost:3000.
SEGV received in SEGV handler [1]
1438 illegal hardware instruction rails s
Note: The latest version of Xcode / command line is installed.
After upgrading the OS successfully (MacOS 10.15.1), I followed the MacPorts migration guide successfully. Further, I successfully reinstalled RVM with Ruby 2.6.1, 2.6.3 and 2.6.5.
Next, installed gem Rails -v 5.2.3 without issue. Tested this out with Rails new TestProj, it created a new project successfully, bundled and started the server with Rails s. No issues and saw the "Yay you're on Rails" page. So far so good.
Then I CD into an existing Rails project, which was built on MacOS 10.14.x (Mojave) did a bundle update without any issues. Followed by a rails s, Puma started without issue. Here's where it gets strange, literally the second I goto the URL "localhost:3000" I immediately get this error.
SEGV received in SEGV handler [1] <- this repeated
1438 illegal hardware instruction rails s
I thought it might be a gem issue, tried installing the same gem set into the TestProj and everything work perfectly with a Puma starting and loading "Yay...". Finally, I've tried cloning the repo, bundling and I get the same error message. I'm pasting what I believe is the most important part of the log file into this post. I wonder if there is something in the Rails app that specifies certain hardware that needs updating? My apologies for its length, Hopefully, someone can interpret this better than I can and help troubleshoot. I'm happy to provide more information. Just not sure what else besides the log file you might need. Let me know. Thanks!
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000000000f8
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: ruby [1438]
VM Regions Near 0xf8:
-->
__TEXT 0000000103679000-000000010367a000 [ 4K] r-x/r-x SM=COW /Users/USER/*
Application Specific Information:
abort() called
Thread 11 Crashed:: thread_pool.rb*
0 libsystem_pthread.dylib 0x00007fff681ac65f pthread_kill + 276
1 libsystem_c.dylib 0x00007fff68077a1c abort + 120
2 libruby.2.6.dylib 0x00000001038261d9 ruby_abort + 9
3 libruby.2.6.dylib 0x0000000103826160 check_reserved_signal_ + 160 (signal.c:854)
4 libruby.2.6.dylib 0x0000000103825fa4 sigsegv + 36 (signal.c:997)
5 libsystem_platform.dylib 0x00007fff681a1b1d _sigtramp + 29
6 ??? 000000000000000000 0 + 0
7 libsystem_c.dylib 0x00007fff68077a1c abort + 120
I expect to cd into the existing RoR application and run rails s to start the server. Then go to http://localhost:3000 and see the application without crashing. The actual results are the following:
...
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
SEGV received in SEGV handler
[1] 16523 illegal hardware instruction rails s
As you can see in the stack trace below, Reminders::FindStaleJobsJob is causing a problem because of the uninitialized constant Reminders. What I don't get is that I don't call Reminders::FindStaleJobsJob anywhere; rather, I call Recaps::FindStaleJobsJob.
I have flushed out the Sidekiq queue and still get this error repeatedly.
2018-09-25T17:45:14.539Z 12784 TID-oxxicof3s INFO: Running in ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin17]
2018-09-25T17:45:14.539Z 12784 TID-oxxicof3s INFO: See LICENSE and the LGPL-3.0 for licensing details.
2018-09-25T17:45:14.539Z 12784 TID-oxxicof3s INFO: Upgrade to Sidekiq Pro for more features and support: http://sidekiq.org
2018-09-25T17:45:14.541Z 12784 TID-oxxicof3s INFO: Starting processing, hit Ctrl-C to stop
2018-09-25T18:00:05.107Z 12784 TID-oxxi975os Recaps::FindStaleJobsJob JID-ec113586e3f8fe72eb3ca479 INFO: start
2018-09-25T18:00:05.135Z 12784 TID-oxxim1crg ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper JID-4bc5f87567ca3f019b2015e4 INFO: start
2018-09-25T18:00:05.136Z 12784 TID-oxxi970ss Recaps::FindStaleJobsJob JID-3125783fd5da7604b95bb813 INFO: start
2018-09-25T18:00:05.155Z 12784 TID-oxxim1crg ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper JID-4bc5f87567ca3f019b2015e4 INFO: fail: 0.02 sec
2018-09-25T18:00:05.155Z 12784 TID-oxxim1crg WARN: {"context":"Job raised exception","job":{"class":"ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper","queue":"default","description":"","args":[{"job_class":"Reminders::FindStaleJobsJob","job_id":"d6161fcf-2abd-4e2b-8946-73668a78282f","queue_name":"default","arguments":[]}],"retry":true,"jid":"4bc5f87567ca3f019b2015e4","created_at":1537898405.1336598,"enqueued_at":1537898405.133705},"jobstr":"{\"class\":\"ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper\",\"queue\":\"default\",\"description\":\"\",\"args\":[{\"job_class\":\"Reminders::FindStaleJobsJob\",\"job_id\":\"d6161fcf-2abd-4e2b-8946-73668a78282f\",\"queue_name\":\"default\",\"arguments\":[]}],\"retry\":true,\"jid\":\"4bc5f87567ca3f019b2015e4\",\"created_at\":1537898405.1336598,\"enqueued_at\":1537898405.133705}"}
2018-09-25T18:00:05.155Z 12784 TID-oxxim1crg WARN: NameError: uninitialized constant Reminders
My Sidekiq cron initializer:
#/config/initializers/sidekiq_cron_scheduler.rb
jobs_hash = {
'recap' => {
'class' => 'Recaps::FindStaleJobsJob',
'cron' => '0, 15, 30, 45 * * * *',
'active_job' => true
}
}
Sidekiq::Cron::Job.load_from_hash jobs_hash
Am I doing something silly and obvious?
Something was hung up somewhere. I removed the Recaps module from the sidekiq-cron initializer and let it fail on that. Then I reintroduced the module name and with a few redis-cli flushall commands sprinkled and there, and everything seems to be working fine.
At work, we have about 1500 test cases, and we manually clean the database using DB.recreate! method before each test. When running all tests using bundle exec rake spec, all tests rarely pass. There are number of tests that fail towards the end of suite with the "Errno::ECONNREFUSED Connection Refused - connect(2) error" errors.
Any help would be much appreciated!
I am using CouchDB 1.3.1, Ubuntu 12.04 LTS, Ruby 1.9.3, and Rails 3.2.12.
Thanks,
EDIT
I looked at the log file more carefully and matched the time tests started failing and error messages that were generated in couchdb log.
[Fri, 16 Aug 2013 19:39:46 GMT] [error] [<0.23790.0>] ** Generic server <0.23790.0> terminating
** Last message in was {'EXIT',<0.23789.0>,killed}
** When Server state == {file,{file_descriptor,prim_file,{#Port<0.14445>,20}},
79}
** Reason for termination ==
** killed
[Fri, 16 Aug 2013 19:39:46 GMT] [error] [<0.23790.0>] {error_report,<0.31.0>,
{<0.23790.0>,crash_report,
[[{initial_call,{couch_file,init,['Argument__1']}},
{pid,<0.23790.0>},
{registered_name,[]},
{error_info,
{exit,killed,
[{gen_server,terminate,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,[<0.23789.0>]},
{messages,[]},
{links,[]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,377},
{stack_size,24},
{reductions,916}],
[]]}}
[Fri, 16 Aug 2013 19:39:46 GMT] [error] [<0.23808.0>] {error_report,<0.31.0>,
{<0.23808.0>,crash_report,
[[{initial_call,
{couch_ref_counter,init,['Argument__1']}},
{pid,<0.23808.0>},
{registered_name,[]},
{error_info,
{exit,
{noproc,
[{erlang,link,[<0.23790.0>]},
{couch_ref_counter,'-init/1-lc$^0/1-0-',1},
{couch_ref_counter,init,1},
{gen_server,init_it,6},
{proc_lib,init_p_do_apply,3}]},
[{gen_server,init_it,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,[<0.23793.0>,<0.23792.0>,<0.23789.0>]},
{messages,[]},
{links,[]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,377},
{stack_size,24},
{reductions,114}],
[]]}}
[Fri, 16 Aug 2013 19:39:46 GMT] [error] [<0.103.0>] ** Generic server <0.103.0> terminating
** Last message in was {'EXIT',<0.88.0>,killed}
** When Server state == {db,<0.103.0>,<0.104.0>,nil,<<"1376681645837889">>,
<0.106.0>,<0.102.0>,<0.107.0>,
{db_header,6,1,0,
{1856,{1,0,1777},95},
{1951,1,83},
nil,0,nil,nil,1000},
1,
{btree,<0.102.0>,
{1856,{1,0,1777},95},
#Fun<couch_db_updater.10.55895019>,
#Fun<couch_db_updater.11.100913286>,
#Fun<couch_btree.5.25288484>,
#Fun<couch_db_updater.12.39068440>,snappy},
{btree,<0.102.0>,
{1951,1,83},
#Fun<couch_db_updater.13.114276184>,
#Fun<couch_db_updater.14.2340873>,
#Fun<couch_btree.5.25288484>,
#Fun<couch_db_updater.15.23651859>,snappy},
{btree,<0.102.0>,nil,
#Fun<couch_btree.3.20686015>,
#Fun<couch_btree.4.73514747>,
#Fun<couch_btree.5.25288484>,nil,snappy},
1,<<"_users">>,"/var/lib/couchdb/_users.couch",
[#Fun<couch_doc.8.106888048>],
[],nil,
{user_ctx,null,[],undefined},
nil,1000,
[before_header,after_header,on_file_open],
[create,
{before_doc_update,
#Fun<couch_users_db.before_doc_update.2>},
{after_doc_read,
#Fun<couch_users_db.after_doc_read.2>},
sys_db,
{user_ctx,
{user_ctx,null,[<<"_admin">>],undefined}},
nologifmissing,sys_db],
snappy,#Fun<couch_users_db.before_doc_update.2>,
#Fun<couch_users_db.after_doc_read.2>}
** Reason for termination ==
** killed
Ah.... The power of the community. I got the following answer from someone in the CouchDB mailing list.
In short, the solution is to change delayed_commit value to false. It's set to true by default, and rapidly recreating multiple databases at the beginning of each test case were creating a race condition (deleting non-existent db, etc.).
This definitely solved my problem.
One caveat is that it has doubled our test duration. That's another problem to tackle, but for now, I am happy with all passing tests.