Many failures in Sequel tests on [RuntimeError] exception expected, not Class: <NoMethodError> Message: <"undefined method `[]' for nil:NilClass"> #2993
Labels
Milestone
Comments
|
Oh nice...I think we've seen reports of this but have been unable to reproduce. This may be our opportunity. Thanks @deepj! |
|
The problem lies somewhere in this method, and appears to only affect our interpreter (JIT passes the spec correctly): def _transaction(conn, opts=OPTS)
rollback = opts[:rollback]
begin
p 1
add_transaction(conn, opts)
begin_transaction(conn, opts)
if rollback == :always
begin
ret = yield(conn)
rescue Exception => e1
raise e1
ensure
raise ::Sequel::Rollback unless e1
end
else
yield(conn)
end
rescue Exception => e
p 2
begin
rollback_transaction(conn, opts)
rescue Exception
end
transaction_error(e, :conn=>conn, :rollback=>rollback)
ret
ensure
p 3
begin
committed = commit_or_rollback_transaction(e, conn, opts)
rescue Exception => e2
begin
raise_error(e2, :classes=>database_error_classes, :conn=>conn)
rescue Sequel::DatabaseError => e4
begin
rollback_transaction(conn, opts)
ensure
raise e4
end
end
ensure
p 4
remove_transaction(conn, committed)
end
end
endWith my stupid logging lines in there, "4" is printed twice. Something in the interpreter is running the ensure block twice. I'm trying to reduce it now. cc @enebo @subbuss |
|
Still unable to reduce this to a non-Sequel example. Here's a longer version with additional output: def _transaction(conn, opts=OPTS)
rollback = opts[:rollback]
begin
p 1
add_transaction(conn, opts)
begin_transaction(conn, opts)
if rollback == :always
begin
p 1.1
ret = yield(conn)
rescue Exception => e1
p 1.2
raise e1
ensure
p 1.3
raise ::Sequel::Rollback unless e1
end
else
p 1.4
yield(conn)
end
rescue Exception => e
p 2
begin
p 2.1
rollback_transaction(conn, opts)
rescue Exception
p 2.2
end
p 2.3
transaction_error(e, :conn=>conn, :rollback=>rollback)
ret
ensure
p 3
begin
p 3.1
committed = commit_or_rollback_transaction(e, conn, opts)
rescue Exception => e2
p 3.2
begin
raise_error(e2, :classes=>database_error_classes, :conn=>conn)
rescue Sequel::DatabaseError => e4
p 3.3
begin
rollback_transaction(conn, opts)
ensure
p 3.4
raise e4
end
end
ensure
p 4
remove_transaction(conn, committed)
end
end
endOutput: |
|
Here's the IR for all passes for the _transaction method in question (with my p's removed): https://gist.github.com/headius/c2bff81379844624a7c2 Somewhere in the early passes this issue gets corrected. Running with |
|
I'm going to hand this off to @enebo because I'm not sure how to go deeper with this. Some pass is cleaning up a bad duplicate of the ensure block, but the current IR debugging output is misleading me. |
|
@headius I'm not sure if this helps but everything seems to work on Ruby 9k pre1... |
|
I suspect this is related to the $! reworking: https://github.com/jruby/jruby/commits?author=subbuss .. |
|
I just tested with b765631 before I started working on it and it still fails. So, I think this is just something about the startup interpreter that we introduce post pre1. Will look for a bit now. |
|
I have nailed the bug, I think. Will have to ponder a bit about the cleanest way to fix it. @headius, @enebo .. The problem is that when control exits an exception region, the rescue pc is not properly popped always. This problem goes away without the non-startup interpreter, because CFG construction takes care of this properly. |
|
I fixed it .. but have to clean it up a bit and see if there is a better solution than adding a boolean 'exitsExcRegion' flag to jump instructions since it bloats memory slightly for the general case. Perhaps another marker instruction? Will play with it a bit. Basically same issue that caused #2776 but a more complex scenario. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are no issues under JRuby 1.7.20. But under JRuby 9k occurs many failures due to the following error (please, see Travis also: https://travis-ci.org/jeremyevans/sequel/jobs/64145749):
How to reproduce:
The text was updated successfully, but these errors were encountered: