Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Segmentation fault #8

Open
ylluminate opened this Issue · 19 comments

8 participants

George Plymale Gopal Patel Wes Morgan fabioperrella Jack Desert John Mair Amadeus Folego Alex Dowad
George Plymale

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?

Gopal Patel
Owner

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.

George Plymale

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.

George Plymale

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.

Gopal Patel
Owner

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

George Plymale

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

Wes Morgan

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?

Gopal Patel
Owner
nixme commented

@cap10morgan Are the places it happens consistent?

Wes Morgan

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

fabioperrella

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

Gopal Patel
Owner
nixme commented

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.

Gopal Patel
Owner
nixme commented

@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

thanks I will try it!

Jack Desert

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?

John Mair
Collaborator

@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

Deleted user

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.

Amadeus Folego
badosu commented

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

Alex Dowad

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

Gopal Patel
Owner

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

Alex Dowad

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.