I am trying to use this gem
https://github.com/AndyObtiva/ultra_light_wizard
When I run...
rails generate ultra_light_wizard:scaffold Project steps:basic_info,project_detail,file_uploads,preview attributes:name:string,description:text,start_date:date,delivery_date:date
The system freezes and I have to interrupt the process to do anything else. What is the best way to trouble shoot the issue? How can I run the command and get feedback on what the code is doing?
Related
I'm trying to integrate Kaltura video's in my Rails project, for which I use the ruby library from Kaltura. I'm running into the problem that my code works fine on console and the exact same code running under rails server causes a nasty crash (or freeze actually, no debug, I have to kill the process manually to be able to restart).
So my questions:
could there be a difference in libraries that both instances are
running? I'm pretty new to the gem stuff, so I don't know if this
could even be possible.
Is there a way to verify (by using a command or such) to check that
both are accessing the same library?
What could be causing such nasty freezes on server without also causing that on the console
Any help is much appreciated!
My question is as simple is that: what code (in the Rails codebase) gets run when you run the rails generate scaffold command? I don't really know how I'd go about figuring that out.
(P.S. The reason I'm interested in this is because I want to track down what I believe to be an esoteric bug in Rails.)
See if this gets you on your way: https://github.com/rails/rails/search?q=scaffold&ref=cmdform
Can someone think of a way to find out where our rails production server hangs? Its CPU is at 99% so I assume it gets lost in a while/for/each loop. Unfortunately we can't find a candidate loop.
The problem does not occur in development and our test suit now has 100% code coverage.
We were already attaching to Ruby via gdb, but didn't know where to go from there.
Any ideas?
Once you have attached with gdb to the busy looping process then call rb_backtrace from gdb:
> call rb_backtrace()
The output from rb_backtrace will be similar to a crash report, and the output will go to your log files similar to a standard Ruby error backtrace.
From there you should hopefully already be a step closer to the solution since you will see where in your Ruby code the process is stuck.
You can check out some more tips here:
http://isotope11.com/blog/getting-a-ruby-backtrace-from-gnu-debugger
This is not a clean solution but at least the following resolved the problem for us: we migrated to the 'thin' webserver and removed 'devise'.
I currently have a problem with a project.
it freezes before it shows the "Started GET ...." seems like it hits an infinite loop.
now i dont really have much experience with debuggers in ROR, can anyone recommend anything i can use to trace the exact origin of the problem. if i can get an error code somewhere then i might be able to fix it.
currently i am using webrick, i tried thin and it gave the exact same error.but i am willing to use anything to find the exact origin of this error.
it seems to be related to the project because all other projects works fine on my environment.
Take a look at the Rails guide on debugging.
Also try running the Rails console ("rails c"); if you can get to a command prompt at all that means that the issue is not in loading the Rails environment (e.g. a problem in application.rb) but is somewhere in the process of making a web request. If there's a failure it may give you a better error message.
I started a blank project with methadone, an awesome framework for building command line apps. The only problem is that I am unable to debug from within the App class that's in bin/my_app
The App class is a file created when you run methadone. Here's how I'm trying to use pry
#!/usr/bin/env ruby
require 'optparse'
require 'methadone'
require 'my_app'
require 'pry'
class App
include Methadone::Main
include Methadone::CLILogging
main do
binding.pry # <= pry here
end
...
When I run rake features I can tell the running process is trying to do something with pry since it pauses for a few seconds. I get the following error and then rake/cucumber is aborted.
process still alive after 3 seconds (ChildProcess::TimeoutError)
I can use pry just fine from the cucumber steps, rspec, or any other place, just not from anywhere in this App class.
One very interesting thing is that if I run my command line app from the console it WILL stop where pry is. It just wont pop into pry when using cucumber.
How can I get the app to work with pry when I'm running rake features?
Update
Sorry, I should clarify that methadone comes with aruba. So my cucumber scenario would look like this
When I successfully run `my_app arg1`
However, it WILL go into debug/pry if I run it with
bundle exec bin/my_app
Use pry-remote to connect to a pry session in the Aruba-managed subprocess.
(Disclosure: I paired with #Dty to come to this solution)
Aruba runs the app in a totally separate process, so I would guess what's happening is that when aruba runs your app, pry starts up at a prompt and waits for input. Since it doesn't get any, aruba times out after three seconds (the default it will wait for an app to complete). This is why you see the "process still alive" issue.
I'm not 100% sure how you could get the standard input of your shell that's running rake features to connect to your app's standard input so you could issue pry commands, but I don't think aruba was designed to allow this.
You have a couple of options:
Tag your scenario with #announce, and use When I run interactively... followed by several When I type - these commands should go to the interactive pry console that's waiting. Kind of kludgy, but it might work
Execute a unit test of your App class. You'll need to replace the call to go! with something like go! if $0 == __FILE__ so that you can require your executable in a test and manipulate App directly.
I have not tried either of these, but the second option feels a bit better and could also be improved with support from the library, if you can figure out a good way to do this.