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

Backtrace in ArgumentError is wrong sometimes #3624

Closed
auroranockert opened this issue Jan 28, 2016 · 10 comments
Closed

Backtrace in ArgumentError is wrong sometimes #3624

auroranockert opened this issue Jan 28, 2016 · 10 comments

Comments

@auroranockert
Copy link

This is on jruby 9.0.4.0 (2.2.2) 2015-11-12 b9fb7aa Java HotSpot(TM) 64-Bit Server VM 24.79-b02 on 1.7.0_79-b15 +jit [darwin-x86_64]

I can't say what exactly is wrong except that the last frame in the Ruby-only trace is wrong, or what is triggering it. My feeling is that the method name and arity message is correct, and that the last frame is just wrong filename/line number. But since it is inside ActiveRecord (which has internals I'm not confident with) I can't say for sure if anything else is wrong.

https://gist.github.com/jensnockert/078e74541c6d50989ce8

@kares
Copy link
Member

kares commented Jan 29, 2016

seems like another AR-JDBC incompatibility with Rails master ... the schema definition is passed wrong number of args?

@auroranockert
Copy link
Author

The incompatability isn't the jruby bug, that part I have fixed. The bug is that the backtrace points to a line that doesn't exist in AR.

@headius
Copy link
Member

headius commented Mar 4, 2016

This looks like it's running with -Xbacktrace.style=full, which prints all internal .java lines and sometimes confounds backtrace-processing libraries. Perhaps that's all that's going on here?

@auroranockert
Copy link
Author

There's a backtrace below that one without -Xbacktrace.style=full, it has the same issue.

@doudou
Copy link

doudou commented Mar 25, 2016

I experience the same problem with, in my case, a TypeError pointing to the wrong place. Not related to Rails or activerecord, it's purely my own code

/home/doudou/dev/rock/toolchain-devel/jruby/tools-roby/lib/roby/execution_engine.rb:247:in `process_events_synchronous'
/home/doudou/dev/rock/toolchain-devel/jruby/tools-roby/lib/roby/event_generator.rb:247:in `call'

The interesting bit is that the line reported in execution_engine.rb is the same than the line in event_generator.rb. The latter makes sense, the former is idiotic (the line points to a attr_reader definition, miles away from the process_events_synchronous method).

One can find the same pattern in the gist from @jensnockert: the next-to-last file/line is good, the last line makes no sense and reports the same line number than next-to-last.

Tested on jruby 9.0.5.0. I'm installing 9.0.3.0 to see if there's the same issue there.

@doudou
Copy link

doudou commented Mar 25, 2016

FYI, jruby 9.0.3.0 has the same issue

@doudou
Copy link

doudou commented Mar 25, 2016

More precisely,

jruby 9.0.3.0 (2.2.2) 2015-10-21 633c9aa Java HotSpot(TM) 64-Bit Server VM 25.74-b02 on 1.8.0_74-b02 +jit [linux-amd64]
jruby 9.0.5.0 (2.2.3) 2016-01-26 7bee00d Java HotSpot(TM) 64-Bit Server VM 25.74-b02 on 1.8.0_74-b02 +jit [linux-amd64]

Both installed using rbenv

@doudou
Copy link

doudou commented Mar 27, 2016

Some more information: the exception in my case is caused by JRuby when calling the method itself (process_events_synchronous), while checking the keyword args. The call is IMO legit, i.e. the exception is probably raised within JRuby's own code, but we'll see about that here

From the point of view of this issue, it looks like the line number is not updated properly when resolving a call, while the file is (the file is the file of the called method, the line number the line number of the call site). This hunch comes from the full backtrace in my case:

    org/jruby/ir/runtime/IRRuntimeHelpers.java:589:in `checkForExtraUnwantedKeywordArgs'
    org/jruby/ir/runtime/IRRuntimeHelpers.java:543:in `checkArity'
    org/jruby/ir/instructions/CheckArityInstr.java:69:in `checkArity'
    org/jruby/ir/interpreter/InterpreterEngine.java:390:in `processBookKeepingOp'
    org/jruby/ir/interpreter/StartupInterpreterEngine.java:111:in `interpret'
    org/jruby/ir/interpreter/InterpreterEngine.java:86:in `interpret'
    org/jruby/internal/runtime/methods/InterpretedIRMethod.java:193:in `INTERPRET_METHOD'
    /home/doudou/dev/rock/toolchain-devel/jruby/tools-roby/lib/roby/execution_engine.rb:661:in `process_events_synchronous'
    org/jruby/internal/runtime/methods/InterpretedIRMethod.java:180:in `call'
    org/jruby/internal/runtime/methods/DynamicMethod.java:197:in `call'
    org/jruby/runtime/callsite/CachingCallSite.java:313:in `cacheAndCall'
    org/jruby/runtime/callsite/CachingCallSite.java:163:in `call'
    org/jruby/ir/interpreter/InterpreterEngine.java:316:in `processCall'
    org/jruby/ir/interpreter/StartupInterpreterEngine.java:77:in `interpret'
    org/jruby/ir/interpreter/InterpreterEngine.java:80:in `interpret'
    org/jruby/internal/runtime/methods/InterpretedIRMethod.java:165:in `INTERPRET_METHOD'
    /home/doudou/dev/rock/toolchain-devel/jruby/tools-roby/lib/roby/event_generator.rb:661:in `emit'
    org/jruby/internal/runtime/methods/InterpretedIRMethod.java:152:in `call'
    org/jruby/internal/runtime/methods/DynamicMethod.java:189:in `call'
    org/jruby/runtime/callsite/CachingCallSite.java:293:in `cacheAndCall'
    org/jruby/runtime/callsite/CachingCallSite.java:131:in `call'
    org/jruby/ir/interpreter/InterpreterEngine.java:332:in `processCall'
    org/jruby/ir/interpreter/StartupInterpreterEngine.java:77:in `interpret'
    org/jruby/ir/interpreter/Interpreter.java:132:in `INTERPRET_BLOCK'
    test/test_event_generator.rb:33:in `block in test_emit_without_propagation_raises'

@kares
Copy link
Member

kares commented Jan 18, 2017

there's no reproduction case here thus if smone is experiencing the issue (on latest 9.1) please include code

@enebo
Copy link
Member

enebo commented May 17, 2017

Yeah I have personally fixed some line number issues since the last update but without something we can run to repro this issue is just languishing. So if someone can make a repro we can sink our teeth into then re-open or create a new issue.

@enebo enebo closed this as completed May 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants