[#69892] [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API — normalperson@...
Issue #11339 has been reported by Eric Wong.
8 messages
2015/07/07
[#69983] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API
— Eric Wong <normalperson@...>
2015/07/15
normalperson@yhbt.net wrote:
[#69990] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API
— SASADA Koichi <ko1@...>
2015/07/16
On 2015/07/16 4:41, Eric Wong wrote:
[#69995] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API
— Eric Wong <normalperson@...>
2015/07/16
SASADA Koichi <ko1@atdot.net> wrote:
[#69984] $SAFE inside an Array — Bertram Scharpf <lists@...>
Hi,
4 messages
2015/07/15
[#70001] [Ruby trunk - Bug #11336] [Open] TestProcess#test_exec_fd_3_redirect failed on Solaris 10 — ngotogenome@...
Issue #11336 has been updated by Naohisa Goto.
4 messages
2015/07/16
[#70005] Re: [Ruby trunk - Bug #11336] [Open] TestProcess#test_exec_fd_3_redirect failed on Solaris 10
— Eric Wong <normalperson@...>
2015/07/16
Sorry, but I think rb_divert_reserved_fd seems a racy fix. I think the
[#70011] [Ruby trunk - Bug #11362] [Open] [PATCH] ensure Process.kill(:STOP, $$) is resumable — normalperson@...
Issue #11362 has been reported by Eric Wong.
3 messages
2015/07/17
[#70016] [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg — merch-redmine@...
Issue #11364 has been reported by Jeremy Evans.
8 messages
2015/07/17
[#70052] Re: [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg
— Eric Wong <normalperson@...>
2015/07/20
merch-redmine@jeremyevans.net wrote:
[#70055] Re: [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg
— Jeremy Evans <code@...>
2015/07/20
On 07/20 10:46, Eric Wong wrote:
[#70056] Re: [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg
— Eric Wong <normalperson@...>
2015/07/21
Jeremy Evans <code@jeremyevans.net> wrote:
[#70103] [Ruby trunk - Feature #11375] Decreased Object Allocation in Pathname.rb — richard.schneeman@...
Issue #11375 has been updated by Richard Schneeman.
3 messages
2015/07/23
[#70156] [Ruby trunk - Bug #11396] Bad performance in ruby >= 2.2 for Hash with many symbol keys — dunric29a@...
Issue #11396 has been updated by David Unric.
3 messages
2015/07/28
[ruby-core:70165] [Ruby trunk - Bug #10969] public_send in combination with method_missing raises NameError instead of NoMethodError
From:
nobu@...
Date:
2015-07-29 06:37:18 UTC
List:
ruby-core #70165
Issue #10969 has been updated by Nobuyoshi Nakada.
Description updated
Backport set to 2.0.0: DONTNEED, 2.1: DONTNEED, 2.2: REQUIRED
----------------------------------------
Bug #10969: public_send in combination with method_missing raises NameError instead of NoMethodError
https://bugs.ruby-lang.org/issues/10969#change-53593
* Author: Yves Senn
* Status: Closed
* Priority: Normal
* Assignee:
* ruby -v: ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-darwin14]
* Backport: 2.0.0: DONTNEED, 2.1: DONTNEED, 2.2: REQUIRED
----------------------------------------
While working on the Rails project, specifically this issue https://github.com/rails/rails/issues/19297 I discovered that `public_send` can raise a `NameError` instead of a `NoMethodError`.
Following is a minimal reproduction scenario to trigger the bug. A more detailed example can be found in this Gist: https://gist.github.com/senny/9864a138defa322ed807
~~~ruby
class Person
def implicit_assignment
nope rescue nil
public_send "nope="
end
def method_missing(*args)
super
end
end
a = Person.new
a.implicit_assignment
# test.rb:13:in `method_missing': undefined local variable or method `nope=' for #<Person:0x007f91d1052ef8> (NameError)
# from test.rb:4:in `public_send'
# from test.rb:4:in `implicit_assignment'
# from test.rb:24:in `<main>'
~~~
### What a found out during debugging:
I am not a C programmer and have very little experience in that field. While debugging the issue I could make some observations what's going on.
The error is being raised in `raise_method_missing` (https://github.com/ruby/ruby/blob/7790f37efdd8dd42a0a43c3206f6afdd43f8e86a/vm_eval.c#L704-L706):
~~~c
else if (last_call_status & NOEX_VCALL) {
format = "undefined local variable or method `%s' for %s";
exc = rb_eNameError;
~~~
`last_call_status` is stored on the current thread (https://github.com/ruby/ruby/blob/7790f37efdd8dd42a0a43c3206f6afdd43f8e86a/vm_eval.c#L655):
The thread struct is modified in `vm_call_method_missing` (https://github.com/ruby/ruby/blob/7790f37efdd8dd42a0a43c3206f6afdd43f8e86a/vm_insnhelper.c#L1668):
~~~c
th->method_missing_reason = ci->aux.missing_reason;
~~~
Now the problem is, that the call to `public_send` with the method name containing an `=` sign, does not modify the thread struct. This means that it still contains the value assigned from the previous call. That's what `nope rescue nil` in the reproduction is used for. It assigns `NOEX_VCALL` to that struct.
--
https://bugs.ruby-lang.org/