pry-nav icon indicating copy to clipboard operation
pry-nav copied to clipboard

Segmentation fault

Open ylluminate opened this issue 13 years ago • 18 comments

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?

ylluminate avatar Feb 08 '12 08:02 ylluminate

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.

nixme avatar Feb 08 '12 08:02 nixme

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 avatar Feb 08 '12 08:02 ylluminate

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 avatar Feb 08 '12 09:02 ylluminate

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

nixme avatar Feb 10 '12 17:02 nixme

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

ylluminate avatar Feb 14 '12 20:02 ylluminate

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 avatar Apr 04 '12 18:04 cap10morgan

@cap10morgan Are the places it happens consistent?

nixme avatar Apr 12 '12 00:04 nixme

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

cap10morgan avatar Apr 12 '12 00:04 cap10morgan

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

fabioperrella avatar Apr 18 '12 17:04 fabioperrella

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 avatar Jun 07 '12 21:06 nixme

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

nixme avatar Jun 12 '12 07:06 nixme

thanks I will try it!

fabioperrella avatar Jun 12 '12 11:06 fabioperrella

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 avatar Sep 06 '12 20:09 jackdesert

@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

banister avatar Sep 07 '12 02:09 banister

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.

ghost avatar Oct 18 '12 19:10 ghost

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

badosu avatar Jun 17 '13 00:06 badosu

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 avatar Jan 14 '14 13:01 alexdowad

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

nixme avatar Jan 14 '14 18:01 nixme

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

alexdowad avatar Jan 14 '14 19:01 alexdowad