-
Notifications
You must be signed in to change notification settings - Fork 648
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
Fix tests #1126
Fix tests #1126
Conversation
nathanielhourt
commented
Jul 7, 2018
•
edited by abitmore
Loading
edited by abitmore
- Fix failing tests
- Move obnoxiously slow test to separate test driver
The main test driver should run fairly quickly; extremely slow tests should be moved to a separate driver so developer time isn't wasted waiting for many runs of a slow test. Really more tests should be moved over, but I'm too lazy right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test case was not broken, so this PR is more an optimization than a fix.
There were efforts to include all consensus related tests into chain_test
. Moving tests outside of chain_test
will likely make them be ignored and may cause unexpected consequences.
auto new_debt = *old_debt + o.delta_debt.amount; | ||
|
||
// Forbid zero collateral with nonzero debt (avoids divide by zero when calculating call price below) | ||
FC_ASSERT(!(new_collateral == 0 && new_debt != 0), "Cannot have zero collateral and nonzero debt"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"zero collateral with nonzero debt" is covered by this test case:
bitshares-core/tests/tests/operation_tests.cpp
Lines 146 to 147 in c6b28b2
BOOST_TEST_MESSAGE( "attempting to claim all collateral without paying off debt" ); | |
GRAPHENE_REQUIRE_THROW( cover( dan, bitusd.amount(0), asset(20000)), fc::exception ); |
price::call_price()
will generate a division-by-zero exception, then the exception will be captured and converted to fc::exception
, then be caught by callers. So I think this change is more an optimization rather than a fix. No?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Incorrect. The test fails, because boost captures the division by zero exception, as it occurs inside the modify functor (line 257), triggering the object to be deleted. As per boost docs, this is expected behavior:
https://www.boost.org/doc/libs/1_67_0/libs/multi_index/doc/reference/ord_indices.html#modify
Exception safety: Basic. If an exception is thrown by some user-provided operation (including mod), then the element pointed to by position is erased.
@@ -145,6 +145,7 @@ BOOST_AUTO_TEST_CASE( call_order_update_test ) | |||
GRAPHENE_REQUIRE_THROW( borrow( dan, bitusd.amount(80000), asset(0)), fc::exception ); | |||
BOOST_TEST_MESSAGE( "attempting to claim all collateral without paying off debt" ); | |||
GRAPHENE_REQUIRE_THROW( cover( dan, bitusd.amount(0), asset(20000)), fc::exception ); | |||
GRAPHENE_REQUIRE_THROW( cover( dan, bitusd.amount(0), asset(20000-1)), fc::exception ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this new test for? Actually it will throw an exception due to triggering a blackswan which is not allowed when updating a call position. It worth testing, but better add a message above it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The underlying implementation now explicitly checks for zero collateral. This test was added to probe the edge case that collateral is not zero, but still too low to sustain the debt. I feel it is sufficiently described by the message, "attempting to claim all collateral without paying off debt"; even though it leaves one unit of collateral unclaimed, the spirit is the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0 and 1 are absolutely different.
@nathanhourt would you please clarify what environment you're using which detected the failing tests? E.G.
Thanks. |
I'm running Arch with clang 6.0.0, boost 1.67.0.
|
Oops, didn't mean to close this... I'm not sure what ci/dockercloud is angry about, as I am apparently forbidden to view the logs. |
Thanks. Boost 1.66+ is known to have issues with current object database and/or undo database implementation. I believe not only these two test cases are affected. More discussions: |
Update: created a new project to track all boost 1.66+ related issues. |
Oh, OK, so it looks like I fixed #852 then? |
…odify() Current boost will delete an object from a multi_index_container if when modifying that object, the functor throws an exception. This breaks the undo infrastructure when it tries to undo the failed change, but the object is missing. To prevent this, we catch the exception before it reaches boost.
501646c
to
7dd4ce0
Compare
Added commit to ensure we don't trip if some other modify functor ever throws in the future |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job.
Does this PR fix #694?
} | ||
} | ||
); | ||
FC_ASSERT(!exception, "Aborting for exception while modifying object"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Best if can re-throw the real exception rather than covering it with a new message and logging it only, so a client program will know what happened.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is true. I went with the lazy option to start, because copying exceptions can be funny, but I'll play with it a bit more
OK, now it throws the original exception rather than a placeholder. As to #694, that looks like a non-issue to me. The original report seems to be that someone was modifying one entry's key to collide with another one? I agree with the discussion on #694, that doesn't make sense to do, and it's not clear what the expected, non-error behavior would be if such a thing were attempted. |
@nathanhourt the Travis building log is public but DockerCloud is not.
|
In other words, hopefully this makes travis work
Travis, you dunce... OK, try this... |
So I can't fix the docker test without some idea as to where it's breaking... Is there something else I can do here? |
@nathanhourt thanks for your contribution. If you're asking me, I'd like to see
Other changes in this PR are mostly fine for me, except some minor issues:
By the way, most core dev team members are on vacation now, I think they'll comment when came back. |