search

nixme / pry-nav

Binding navigation commands for Pry to make a simple debugger
MIT License
390 stars 35 forks source link

Segmentation fault #8

Open ylluminate opened 12 years ago

ylluminate commented 12 years ago

I was nexting a line of code which threw me into mon_synchronize line 213 "mon_exit"

  208:   def mon_synchronize
  209:     mon_enter
  210:     begin
  211:       yield
  212:     ensure
=> 213:       mon_exit
  214:     end
  215:   end
  216:   alias synchronize mon_synchronize
  217: 
  218:   #

and then got the following segfault: https://gist.github.com/b1dfb8aa85199cf36efc

Any idea as to where to go with this?

nixme commented 12 years ago

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.

ylluminate commented 12 years ago

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.

ylluminate commented 12 years ago

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.

nixme commented 12 years ago

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

ylluminate commented 12 years ago

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

cap10morgan commented 12 years ago

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?

nixme commented 12 years ago

@cap10morgan Are the places it happens consistent?

cap10morgan commented 12 years ago

@nixme No, but they were quite common. I could produce a few backtraces and whatever other context if that would help.

fabioperrella commented 12 years ago

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

nixme commented 12 years ago

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.

nixme commented 12 years ago

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

fabioperrella commented 12 years ago

thanks I will try it!

jackdesert commented 12 years ago

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?

banister commented 12 years ago

@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

ghost commented 12 years ago

I have a consistent case for you.

1 require 'ipsum' 2 require 'pry' 3 require 'pry-remote' 4 require 'pry-nav' 5 6 class TestDataGenerator 7 def generate_domain 8 binding.pry 9 a = 5 10 b = 10 11 end 12 end 13 14 gen = TestDataGenerator.new 15 gen.generate_domain

remove ipsum and everything works fine.... single step past line 9 and everything will crash otherwise.

badosu commented 11 years ago

@ghost 's repro works under 2.0.0, but crashes on 1.9.3-p429.

alexdowad commented 10 years ago

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

nixme commented 10 years ago

@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/

alexdowad commented 10 years ago

OK, will do. If that is the official resolution for this problem, you might as well close the GH issue.