Java::JavaLangInvoke::WrongMethodTypeException when using invokedynamic #4148
Comments
|
From that trace it's not possible to tell where in your code it failed, and that would be helpful information. If you are able to run your specs while passing I may be able to figure out the problem by just looking at JRuby code too, but that flag about would help. Priority for 9.1.6.0. |
|
I feared that this backtrace won't help much. If I only run it with Let me know how else I can help while trying to get the failing codebase down to something sharable. |
|
That's actually close! If you can also pass |
|
doing the following I got this |
|
Ok, great. So whatever attribute accessor is being called at |
|
so the |
|
No luck so far reproducing this. |
|
If you could, add this line above the puts method(:delegate).source_locationAnd give me the output. The problem here seems to be that the |
|
seems to be the one from active_support |
|
Hmm, indeed it does. So much for that theory. I have a possible fix for this but I'm still very confused why it's seeing this method as an attribute accessor. |
I'm still baffled as to why we'd be following either of these paths for a plain Ruby method (ActiveSupport's "delegate" method in #4148) but this should at least prevent us from attempting to bind those methods at attrs.
|
I have pushed a fix to master that should prevent this from happening. It's still rather a mystery why it happened at all...and I hate unsolved mysteries. If you can build JRuby, give it a try. Otherwise check http://ci.jruby.org for a snapshot build after this post (I'll try to kick one off now. |
|
I just got around testing a snapshot ( Maybe next week I find some time to try creating something reproducible. So the mystery can be solved properly. |
|
I managed to create a reproducible example (not sure if it could have been more minimal) and pushed it here https://github.com/andreaseger/jruby_indy_wrong_method_type_exception_example Maybe this helps finding out why this is happening in the first place |
|
@andreaseger Great, thank you! I'll have a look at your repro. |
|
Ah-ha, now I see why the line numbers didn't make any sense; delegate causes new methods to be eval'ed with file and line number set to the location of the delegate call. So the problem was not in that call but in one of the eval'ed methods. And now I have my answer. The problem is that this attempts to call an attribute accessor generically using I'll have a proper spec shortly, and I'll see if I can improve the binding for these cases. |
|
Trivial reproduction: |
|
I've added a spec and I'm satisfied with the fix. Calling an attribute reader in this way will not optimize as well as calling it with no arguments, but because of the variable nature of splats it's tricky to make this a direct operation. As it is, the empty array still would get created anyway. I'll be getting jit specs running under indy today. |
Environment
Provide at least:
uname -a)I'm getting the following errors when running parts of my test suite of a big sinatra application using jruby 9.1.5.0 with invokedynamic enabled. The test suite is running fine without indy.
Please let me know how I can give you more information if needed. In the meantime I'll try to isolate the issue to a smaller part of our codebase.
Expected Behavior
The tests and code to run successfully
Actual Behavior
specs start to fail with the following error. Some of these specs will work if run in isolation. Others fail even if executed alone. I haven't yet been able to figure out a more precise cause as the consistently failing specs are bigger integration specs which touch quite a big surace. But suspect some jiting issue given other specs which work in isolation.
What I find also interesting is that after the error occurs the first time not necessary all following specs fail too. From what I see related codes also fails while other codeparts keep working as intended.
The text was updated successfully, but these errors were encountered: