method `method_missing' called on terminated object

[wycats]

When running the Handlebars tests on some machines, I routinely get:

  1) Tokenizer tokenizes inverse sections as 'OPEN_INVERSE CLOSE'
     Failure/Error: out << Token.new(result, lexer.yytext)
     NotImplementedError:
       method `method_missing' called on terminated object (0x007f8d24a4db80 flags=0x0 klass=0x0)
     # ./spec/tokenizer_spec.rb:22:in `tokenize'
     # ./spec/tokenizer_spec.rb:159:in `block (2 levels) in <top (required)>'

[cowboyd]

If I had to guess I'd say that this http://bugs.ruby-lang.org/issues/4168

Under my stress tests, the stlib WeakRef implementation was very unreliable. It didn't take long at all for this exact issue to manifest all over the place.

We now use https://github.com/bdurand/ref to mitigate. Let me see if I can get your test suite running on master.

[jeyb]

I'm running into this problem off of 0.11.0beta8. Was it fixed in any commit after that release?

[cowboyd]

Unfortunately this is a bug in YARV that I've been unsuccessful at working around completely. Using the ref gem helps, but it does not catch all of the cases. It's one of those nasty ones that requires a lot of time to track down. Perhaps it's time to appeal to an internals guru.

[brupm]

Seeing the same issue.

[orslumen]

Also see this from time to time. I am using 0.11.0beta8 on ruby 1.9.3p194.

Is there a way to skip using weak references at all? I prefer consuming more memory over a failing program.

[SamSaffron]

ha ... just got this on p392

[SamSaffron]

I will self reply here, current thinking is that to fully resolve you need to be running Ruby 2.0 , see comment

https://github.com/cowboyd/therubyracer/blob/master/lib/v8/weak.rb

[bandframe]

@SamSaffron Rubinius also has a functioning weakref implementation.

[djiang]

I'm seeing this on 0.10.1 with Ruby 1.9.3p392. Can anyone confirm that it's happening on with version 0.11.4?

Edit: I updated to 0.11.4 and was still seeing this issue intermittently.

Here my stack trace:

/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/object.rb:33:in `block (2 levels) in each'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/array.rb:8:in `block (2 levels) in each'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/array.rb:7:in `each'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/array.rb:7:in `block in each'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/portal.rb:24:in `block (2 levels) in open'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/context.rb:98:in `enter'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/portal.rb:23:in `block in open'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/portal.rb:16:in `lock'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/portal.rb:22:in `open'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/array.rb:6:in `each'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/object.rb:32:in `block in each'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/portal.rb:24:in `block (2 levels) in open'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/context.rb:98:in `enter'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/portal.rb:23:in `block in open'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/portal.rb:16:in `lock'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/portal.rb:22:in `open'
/Users/david/.rvm/gems/ruby-1.9.3-p392/gems/therubyracer-0.10.1/lib/v8/object.rb:31:in `each'

[jfirebaugh]

I get this frequently on the skim test suite. Example

[cowboyd]

@jfirebaugh sadly, there is no easy fix due to fundamental defects in the WeakRef implementation on 1.9.3

There may be a more solid workaround, than what the ref gem provides, but I personally don't have the bandwidth to make this a priority given that it works on rubinius and MRI 2.0

I wish I had a better answer than that of course, but there you have it.

[SamSaffron]

wild thought, could we have switch that in test disables the weakref stuff
altogether, just leaks a tad more memory?

On Fri, Jun 28, 2013 at 4:59 AM, Charles Lowell notifications@github.comwrote:

@jfirebaugh https://github.com/jfirebaugh sadly, there is no easy fix
due to fundamental defects in the WeakRef implementation on 1.9.3

There may be a more solid workaround, than what the ref gem provides, but
I personally don't have the bandwidth to make this a priority given that it
works on rubinius and MRI 2.0

I wish I had a better answer than that of course, but there you have it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/176#issuecomment-20147324
.

[cowboyd]

It is possbile, and I've been toying with the idea of adding an explicit Context#destroy() method to mark in code when you are done with it and all of its objects can be freed by the runtime.

[SamSaffron]

@cowboyd that would be awesome, mainly looking for a workaround for our test suite

[steel]

Any updates? We're seeing this randomly as well.

[ljharb]

We're also seeing this randomly - a workaround for tests would be amazing.

[SamSaffron]

I would say best thing to do would be to upgrade to ruby 2.0 ... 1.9.3 had
its day :)

On Thu, Feb 6, 2014 at 11:56 AM, Jordan Harband notifications@github.comwrote:

We're also seeing this randomly - a workaround for tests would be amazing.

Reply to this email directly or view it on GitHubhttps://github.com//issues/176#issuecomment-34281213
.

[ljharb]

That's an unreasonable thing to expect businesses to do quickly. We'd certainly like to move to Ruby 2, but it's going to be quite awhile - so if therubyracer won't let us run tests, we'd have to find something that did, and we'd be unlikely to switch back.

Hopefully someone can help come up with a workaround so there's an upgrade path for therubyracer users :-)

[jneen]

We're running into this too and have significant ops hurdles for deploying with ruby 2.0. I just finished putting a blanket rescue-retry with max 20 retries around a migration we're running, which makes me extremely sad - especially since the errors are often "no such method for nil", which is super-general.