I'm using daemons gem with Rails in addition to daemon_generator plugin. I'm getting this output in the daemons log file:
Logfile created on Sat May 09 20:10:35 -0700 2009 by /
-below you find the most recent exception thrown, this will be likely (but not certainly) the exception that made the application exit abnormally ***
#<NameError: uninitialized constant SmsMessage>
-below you find all exception objects found in memory, some of them may have been thrown in your application, others may just be in memory because they are standard exceptions ***
#<NoMemoryError: failed to allocate memory>
#<SystemStackError: stack level too deep>
#<fatal: exception reentered>
#<MissingSourceFile: no such file to load -- ./config/global_constants.conf>
#<NameError: uninitialized constant SmsMessage>
I'm finding very hard to make sense from this output. It's displaying different error messages and I can tell it's not it's not the ./config/global_constants.conf issues because I don't call it inside the daemon file. Plus I don't think it's a memory issues as my Mac has 2GB of memory and not many programs running. as for the SmsMessage I'm calling it normally using:
scheduledMessagesParent = SmsMessage.valid.find(:all, :conditions => {:status => $SCHEDULED_MESSAGE})
which works elsewhere in my website!!
I noticed that the logger is called using
ActiveRecord::Base.logger.info "....
Is it possible I have to specify my model's path in another way? I normally call the logger using logger.info without the need for ActiveRecord::Base. If so how to do that?
Any ideas how to go about debugging this problem? is there a way to display stack trace or better error messages?
I resolved this issue by loading the Rails environment with the Daemon. It wasn't included in the tutorial that I got the info from but it works now :)
Related
Let's say you have the following example code block:
def next_page(next_token)
client.list_order_items_by_next_token(next_token)
rescue => error
binding.pry
end
Without diving into the issue that this rescue is capturing all errors and how that is bad (this block has been modified) is there a way to determine the method list_order_items_by_next_token caused the issue? I know the stack trace is available but that does not feel right.
Just use
error.backtrace
Don't worry about performance.
By the time you rescue the exception the cost of creating the backtrace has already occurred. The backtrace is created when the exception is raised. And it is expensive! Ruby has to create O(N) new strings whenever an exception is raised, where N is the depth of the stacktrace. Which can be 1000+ in a common Rails application. It gets even worse in a loop. And all these strings are usually never used and just clog up garbage collection. In our production system those backtrace strings are one of the major causes of performance degradation. But as I said, that cost occurs when the exception is raised, accessing the backtrace later is free of cost.
I am used to PHPUnit, so I found RSpec to be inferior when it comes to showing what has gone wrong, where and why.
For example, in PHPUnit, I can get the stack trace when an exception is raised (and even with -b option in RSpec, all I can get is the stack trace of RSpec exceptions, and not Rails's)
Also, when some error occurs, it shows you the ACTUAL value and the EXPECTED value.
Those two features I'd like to achieve in RSpec. Getting a detailed error message that includes the stack trace, in case of an Exception of Ruby or of Rails, and to know what was the actual value.
Any ideas of how to accomplish this?
If you run
rspec --help
you will see all the options you can pass (or configure via RSpec.configure) to the runner. One of the will force RSpec to show the entire backtrace
-b, --backtrace Enable full backtrace.
You can also configure the excluded/included lines to control how deep you want the backtrace to go.
As for the actuals vs expected value, this is supported by default in RSpec. See for example
For custom-defined objects, it also print out a diff.
I'm using Cucumber with capybara-webkit for my app's integration tests on Ruby 2.0.0, Rails 4.1. A handful of test in my cucumber test suite unexpectedly began spitting out errors like this:
Circular dependency detected while autoloading constant UiValidators::ParameterFinder (RuntimeError)
/Users/kingp/.rvm/gems/ruby-2.0.0-p451#triquest/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:484:in `load_missing_constant'
/Users/kingp/.rvm/gems/ruby-2.0.0-p451#triquest/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:180:in `const_missing'
/Users/kingp/Projects/rails-triquest/app/controllers/contacts_controller.rb:2:in `<class:ContactsController>'
/Users/kingp/Projects/rails-triquest/app/controllers/contacts_controller.rb:1:in `<top (required)>'
/Users/kingp/.rvm/gems/ruby-2.0.0-p451#triquest/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:247:in `require'
...
The error says 'circular dependency', but it is actually thrown at any time the Rails autoloader tries to load a constant that is already in its set of loaded constants. Typically this is indeed due to a circular dependency, but I'm pretty sure that's not the case in my app. A diff between the branch with the crashing test and the stable branch I forked from shows that the only changes are to coffeescript files, view templates, a migration, and the new cucumber features I was writing. I haven't touched any controller or model code.
I ended up inserting some logging code into the rails autoloader to help me figure out what's going on:
# Inserted at activesupport-4.1.1/lib/active_support/dependencies.rb:467
_thread_id_for_debug = Thread.current.object_id
STDERR.puts "*** #{loaded.count} #{from_mod} #{const_name} - #{_thread_id_for_debug}"
loaded is a set of paths to autoloaded code files, from_mod the context where the request came from, const_name the constant we're trying to load. Which all ultimately got me this, immediately before the crash:
*** 104 Object SitesController - 70180261360940
*** 105 Object ContactsController - 70180240113760
*** 105 SitesController UiValidators - 70180261360940
*** 105 Object UiValidators - 70180261360940
*** 105 UiValidators ParameterFinder - 70180261360940
*** 107 UiValidators ParameterFinder - 70180240113760
It looks like two threads are attempting to autoload the same constant. My guess is that the name of the constant is added to Rails' set of 'loaded' constants by the first thread before it has finished loading. The second thread can't resolve the constant (since the load hasn't finished yet), asks the autoloader to find it, and the autoloader raises when it sees the constant in its 'loaded' set.
At this point in the test, two controllers (SitesController and ContactsController) are responding to AJAX requests, launched nearly simultaneously.
I have found a way to work around the crash, by just including a reference to the module UiValidators::ParameterFinder ahead of the AJAX. But this seems fragile, and also not very elegant. Short of turning on eager loading for the test environment, is there any other way to avoid this problem?
I had the same problem (without Cucumber, just Capybara & Poltergeist). setting config.eager_load = true didn't even work for me (don't quite understand why not..).
I ended up using Spring and haven't had a circular dependency error since.
I have the same issue with Rails 4.1.4 when using Sidekiq. I assume that a race condition inside the threaded Sidekiq workers caused all kinds of hijinks when const_missing inside active_support was called.
In addition to make sure that my current environment would perform eager loading i.e. via config.eager_load = true I also had to add all components that my workers were using from the lib directory into config.eager_load_paths (via config.eager_load_paths += %W(#{config.root}/lib) inside config/application.rb).
This was necessary because I assume that setting config.eager_load = true only makes Rails eager load the contents of the app/ directory.
App::Application.config.eager_load_paths
=> [
[0] "/home/archive/releases/20140721180504/app/assets",
[1] "/home/archive/releases/20140721180504/app/controllers",
[2] "/home/archive/releases/20140721180504/app/helpers",
[3] "/home/archive/releases/20140721180504/app/mailers",
[4] "/home/archive/releases/20140721180504/app/models",
[5] "/home/archive/releases/20140721180504/app/services",
[6] "/home/archive/releases/20140721180504/app/workers"
]
The combination of both seemed to have helped with the issue.
Resque-web is up and running but when trying to view the failed jobs I get the following error:
NoMethodError at /failed
undefined method `to_yaml' for 3:Fixnum
The stack trace points to a 'to_yaml' call as mentioned in the error, it seems like resque-web is missing a requires. Has anyone else had this problem or know how to solve it?
Note: I'm running this locally on a rails 4 app.
You can see the reason here: https://github.com/resque/resque/issues/1143 -- it boils down to a temporary bug that is fixed, but not released yet. I fixed mine by adding
require 'yaml'
at the top of the server.rb file
note that the server.rb file on my machine was located at:
/usr/local/lib/ruby/gems/2.0.0/gems/resque-1.25.1/lib/resque/server.rb
your location may vary
I've got problem with migrating rails 2.x -> 3.2.13
At some point, after fixing a few things, I get Completed 500 Internal Server Error in 76ms without any traceback.
development.rb
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
Why there is no traceback and how to fix this?
you probably solved it but I wanted to share my couple of hours debugging about this issue as it can be very annoying. In short, I was having the same problem - 500 internal server error without any log of the exception thrown. It was happening only for exceptions thrown in the action view templates - any ActionView::Template::Error exception. For example, missing partial, invalid route.
My specific problem was using this ruby statistics module:
http://derrick.pallas.us/ruby-stats/
directly in the initializers directory which works great in rails 2.x. It defined Array.sum method which is already defined in rails 3 under Enumerable.sum. The problem with the redefine is that Array.sum no longer works with arrays of strings which is what rails was trying to do with ActionView::Template::Error.source_extract method - when trying to extract the source of the error in template, it uses the Enumerable.sum method which is redefined in a wrong way. Thus, another exception happened TypeError: cannot convert String into Fixnum and the original exception was not logged, neither was the new one. I had to do a backtrace and go through many of the internal calls to see where is the issue.
So, for everyone not seeing the actual exceptions thrown in your ActionView templates, check if you have not redefined a rails method that is used internally in rails.