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

Already on GitHub? Sign in to your account

update for current version #14

merged 25 commits into from Oct 8, 2011


None yet
8 participants

nobu commented Aug 18, 2011

No description provided.

Hello @mark-moseley, @nobu request correct ruby-debug behavior under Ruby 1.9.3.

This was reported as a Ruby bug:


With the upcoming 1.9.3 release, can you take a look and let us know any possible issue?

Thank you.

/cc @cfis


mark-moseley commented Sep 3, 2011

Luis, yes, I am planning to incorporate his changes once I get a moment to look at it.

As I understand it, it's specific to the Visual Studio compiler (or all non-gcc compilers?), which I'm not set up to use at the moment. Can you assist with testing?


nobu commented Sep 3, 2011

No, it's for all compilers, gcc and VC at least.

cfis commented Sep 4, 2011

Nobu is correct, this is for all compilers across all operating systems.

One thing I am confused about though is this branch being maintained anymore? All the recent activity has been on the JetBrains branch:


Are you guys working together or are these two separate efforts now? Where should this patch go?



mark-moseley commented Sep 4, 2011

I'm confused then, because I can compile 1.9.3-preview1 on Linux/gcc. What does this fix exactly?

You should try ruby_1_9_3 branch instead than preview1 release


mark-moseley commented Sep 4, 2011

My intention is to maintain this branch. JetBrains has some additional fixes. I haven't seen their test cases so I haven't incorporated them.

cfis commented Sep 4, 2011

Got it, thanks for the info.

So the particular issue I have is that ruby-debug-base19 no longer compiles against the ruby_1_9_3 branch. The preview released did compile fine because the change in question was after that, see:


The result of this change is using GetThreadPtr results in linker errors because ruby_threadptr_data_type became private, so its not exported from the ruby dll on windows (gcc or vc++). This apparently happens on debian too - see http://rubyforge.org/tracker/index.php?func=detail&aid=29222&group_id=8883&atid=34290.

Since ruby-debug uses GetThreadPtr, its cannot be compiled anymore, and thus no longer works.

cfis commented Sep 4, 2011

FYI - I'm happy to test on windows and fedora...


mark-moseley commented Sep 5, 2011

@nobu: using the current ruby trunk (1.9.4dev 33177), I've incorporated your changes. I also had to add your ruby_current_thread fix to linecache19. Now I'm getting the following error:

dyld: lazy symbol binding failed: Symbol not found: _rb_method_entry
Referenced from: /usr/local/ruby193/lib/ruby/gems/1.9.1/gems/ruby-debug-base19-0.11.26/lib/ruby_debug.bundle
Expected in: flat namespace


I was going to test this with 1.9.3dev but I don't see where this is: 'ruby_current_thread fix to linecache19'

If you merge these changes into topic branches for ruby-debug and linecache19 I can easily reference them with bundler and then very easily test with applications on 1.9.3dev or 1.9.4dev


cfis commented Sep 8, 2011

Nobu/Mark, any progress on this? Happy to help if needed.

Thanks - Charlie


mark-moseley commented Sep 8, 2011

@stepheneb: no need to test until I get a resolution to the rb_method_entry symbol not found issue (and whatever other unresolved externals that might come after that). I'm not going to check in changes until they are somewhat stable.

@cfis: I'm stuck until I get nobu's help on rb_method_entry issue

cfis commented Sep 9, 2011

Hi Mark - Thanks for the update. I'll update the ticket on Ruby bug tracker.

cfis commented Sep 13, 2011

Just being a pain and bringing this up again ... I updated the Ruby tracker ticket also.

cfis commented Sep 16, 2011

Hi Mark - If you have a moment, there are some questions about why ruby-debug needs to use id2ref and ref2id on the ruby tracker ticket this issue started with. See:


kosaki commented Sep 16, 2011


We who ruby 1.9.3 release team plan to release 1.9.3-rc1 at this weekend and release 1.9.3p0 at next week. PLEASE join to ruby-core discussion and hopefully makes productive conclusion. This issue has a very little discussion time anymore.


Thank you.


mark-moseley commented Oct 8, 2011

I've merged in Nobu's changed. Updated gems (linecache19 0.5.13 and ruby-debug-base19 0.11.26) are at RubyForge, on the files section for ruby-debug19 (http://rubyforge.org/frs/?group_id=8883)

@mark-moseley mark-moseley added a commit that referenced this pull request Oct 8, 2011

@mark-moseley mark-moseley Merge pull request #14 from nobu/master
update for Ruby 1.9.3-rc1

@mark-moseley mark-moseley merged commit 262e25d into mark-moseley:master Oct 8, 2011

Ah, very cool -- are you planning to push to rubygems.org?


mark-moseley commented Oct 8, 2011

Once it's stable, yes. I'm seeing some segmentation faults in some of the regression tests.

Ah.. Well I'm having great results on Ruby 1.9.3-rc1! Thank you!

Dagnan commented Oct 16, 2011

Hi all.
Using linecache19, ruby-debug-base19 last versions from Github, I still get odd errors running tests from my Rails 3 app.

/path/to/home/.rvm/gems/ruby-1.9.3-rc1/bundler/gems/ruby-debug-017231853480/lib/ruby-debug-base.rb:38:in `handler': No interface loaded (RuntimeError)
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/bundler/gems/ruby-debug-017231853480/lib/ruby-debug-base.rb:46:in `at_catchpoint'
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/gems/activesupport-3.0.9/lib/active_support/dependencies.rb:239:in `block in require'
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/gems/activesupport-3.0.9/lib/active_support/dependencies.rb:225:in `block in load_dependency'
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/gems/activesupport-3.0.9/lib/active_support/dependencies.rb:596:in `new_constants_in'
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/gems/activesupport-3.0.9/lib/active_support/dependencies.rb:225:in `load_dependency'
    from /path/to/home/.rvm/gems/ruby-1.9.3-rc1/gems/activesupport-3.0.9/lib/active_support/dependencies.rb:239:in `require'

Is it because these version are not the same as on Rubyforge?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment