Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation fault #8

Open
ylluminate opened this issue Feb 8, 2012 · 18 comments
Open

Segmentation fault #8

ylluminate opened this issue Feb 8, 2012 · 18 comments

Comments

@ylluminate
Copy link

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
Copy link
Owner

nixme commented Feb 8, 2012

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
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

nixme commented Feb 10, 2012

@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
Copy link
Author

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
Copy link

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
Copy link
Owner

nixme commented Apr 12, 2012

@cap10morgan Are the places it happens consistent?

@cap10morgan
Copy link

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

@fabioperrella
Copy link

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
Copy link
Owner

nixme commented Jun 7, 2012

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
Copy link
Owner

nixme commented Jun 12, 2012

@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
Copy link

thanks I will try it!

@jackdesert
Copy link

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
Copy link
Collaborator

banister commented Sep 7, 2012

@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
Copy link

ghost commented Oct 18, 2012

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
Copy link

badosu commented Jun 17, 2013

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

@alexdowad
Copy link

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
Copy link
Owner

nixme commented Jan 14, 2014

@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
Copy link

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants