I was nexting a line of code which threw me into mon_synchronize line 213 "mon_exit"
208: def mon_synchronize
=> 213: mon_exit
216: alias synchronize mon_synchronize
and then got the following segfault: https://gist.github.com/b1dfb8aa85199cf36efc
Any idea as to where to go with this?
I've been seeing segfaults randomly on 1.9.3 as well, but haven't spent anytime on a reproducible case. Any chance you can distill your code down to something reproducible? Then we can inspect with gdb and see what's causing the actual fault.
You know, I just saw something interesting. It does seem to be reproducible, however it seems as though someone added a bug in the sql and so I think it's segfaulting on the Mysql2::Error. Oddly though still when I next onto that following query after I've fixed the source it will hang and a control-c brings it back and it will then continue on.
Oh, also, is there a step over function? For example, I don't really want to step into the guts of an AR query, I'd like to simply allow it to do it's thing and end up on the other side of it. Presently next seems to just jump on into the details of the method and this is not desirable much of the time for me. In other words, I expected next to function like gdb by going "over" the function and step to step on into the method.
@ylluminate, I got a small test program that segfaults occassionally but not consistently. I believe the issue crops up with ensure.
You're also right about next, it should jump to the next line in the same file, while step should step into the method call. pry-nav tracks location by using a count of frames in the stack. What you're seeing is a bug in that tracking. I'll investigate further.
Thanks for that update, @nixme. I ended up seeing another failure that I wanted to push your way. I was simply running step instead of next since next seems to skip so much and just continue on, but then ran into a crash whilst in the ruby csv lib: https://gist.github.com/35ffdd5d7be3549f4f02
I'm seeing quite a few segfaults on "next" in various places with my Rails 3.2.2 app running on Ruby 1.9.3-p125. Is there any info I can provide to help debug?
@cap10morgan Are the places it happens consistent?
@nixme No, but they were quite common. I could produce a few backtraces and whatever other context if that would help.
Same problem for me, but i'm using mongoid, so I think the problem is not in Mysql2, my stacktrace: https://gist.github.com/2415318
I'm getting tired of the segfaults in 1.9.3 as well. I'm trying a new approach using the debugger gem (formerly ruby-debug) at https://github.com/nixme/pry-debugger. Should be faster since it doesn't use set_trace_proc. Try it out. Let me know if it works any better. Still really raw, so it might have odd stepping behavior.
Funny how a C-extension might be more stable than a pure ruby approach.
@fabioperrella, @GitHub-RailsCast, @ylluminate pry-debugger is ready for real use. Same commands as pry-nav, but faster, and supports breakpoints. Let me know if you still get segfaults with it.
thanks I will try it!
I'm getting segmentation faults with pry-debugger / guard / spork / Postgres / Mongoid. It happens with either Ruby 1.9.2 or 1.9.3. Consistently. Do we have a fix yet?
@jackdesert can you provide a backtrace/sample session showing the segfault and the situation it arises? also if you had a small test case with a Gemfile that reproduces the bug that would be useful
I have a consistent case for you.
1 require 'ipsum'
2 require 'pry'
3 require 'pry-remote'
4 require 'pry-nav'
6 class TestDataGenerator
7 def generate_domain
9 a = 5
10 b = 10
14 gen = TestDataGenerator.new
remove ipsum and everything works fine.... single step past line 9 and everything will crash otherwise.
@ghost 's repro works under 2.0.0, but crashes on 1.9.3-p429.
I get segfaults all the time when stepping through Rails code with pry-nav on MRI 1.9.3... I hardly ever have problems with non-Rails Ruby programs, but crashes are very common when debugging Rails code... :(
@alexdowad If you're on 1.9.3, please switch to pry-debugger as the README mentions. It's faster and should work better without segfaulting.
The segfaults are in the ruby interpreter since pry-nav is pure ruby code. However 1.9.3 is being end-of-lifed as mentioned here: https://www.ruby-lang.org/en/news/2014/01/10/ruby-1-9-3-will-end-on-2015/
OK, will do. If that is the official resolution for this problem, you might as well close the GH issue.