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

Market Ticker going crazy #1883

Closed
sschiessl-bcp opened this issue Aug 6, 2019 · 6 comments

Comments

@sschiessl-bcp
Copy link

commented Aug 6, 2019

Bug Description
Market ticker giving crazy values, e.g. asset ABCWORLDSERIES on testnet. The value returned by "get_ticker" backend call has as base_volume 3402823669209384634633745944781682.11456. What's breaking there?

Impacts
Describe which portion(s) of BitShares Core may be impacted by this bug. Please tick at least one box.

  • API (the application programming interface)
  • Build (the build process or something prior to compiled code)
  • CLI (the command line wallet)
  • Deployment (the deployment process after building such as Docker, Travis, etc.)
  • DEX (the Decentralized EXchange, market engine, etc.)
  • P2P (the peer-to-peer network for transaction/block propagation)
  • Performance (system or user efficiency, etc.)
  • Protocol (the blockchain logic, consensus, validation, etc.)
  • Security (the security of system or user data, etc.)
  • UX (the User Experience)
  • Other (please add below)

Steps To Reproduce
Steps to reproduce the behavior (example outlined below):

  1. Connect to testnet
  2. Execute API call 'get_ticker' for market of ABCWORLDSERIES and its collateral
  3. Observe weird numbers

Expected Behavior
Ticker returns actual volume

CORE TEAM TASK LIST

  • Evaluate / Prioritize Bug Report
  • Refine User Stories / Requirements
  • Define Test Cases
  • Design / Develop Solution
  • Perform QA/Testing
  • Update Documentation

@abitmore abitmore added this to the 3.3.0 - Feature Release milestone Aug 6, 2019

@abitmore abitmore added this to To do in Feature Release (3.3.0) via automation Aug 6, 2019

@abitmore abitmore self-assigned this Aug 6, 2019

@abitmore

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

Reproduced on my testnet node, which was test-3.2.0 built in Ubuntu 16.04 with default GCC (5.4) and openssl and boost libraries (1.58).

Looks like that number is 2**128. That's a GSed PM, with an outcome 1. Price of the last fill_order_operation is 1. The volume should be 0. Also happens on some of other assets (but not all).

Since data type of the volume types is fc::uint128, the range should be [0, 2**128), it's strange that to_string() converted 0 to that string.

$ curl -d '{"id":1,"method":"call","params":["database","get_objects",[["5.2.0"]]]}' https://node.testnet.bitshares.eu/ 2>/dev/null|jq 
{
  "id": 1,
  "jsonrpc": "2.0",
  "result": [
    {
      "id": "5.2.0",
      "base": "1.3.0",
      "quote": "1.3.7",
      "last_day_base": 30000000,
      "last_day_quote": 10000000,
      "latest_base": 30000000,
      "latest_quote": 10000000,
      "base_volume": "340282366920938463463374607312938211456",
      "quote_volume": "340282366920938463463374607392158211456"
    }
  ]
}
@abitmore

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

OK, that number is not 2**128, but is a little smaller. The issue happens when an asset is globally settled, following force-settle orders will produce no maker fill_order record in market history but only taker records, thus volume of the last history record gets subtracted from the total volume again and again on every new block, thus causes integer underflow. I'll fix.

@abitmore

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

Update: I was wrong about the reason why the volume gets subtracted by a number on every new block. Will update later.

@abitmore

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

There was a bug when rolling the 24-hour fill_order history buffer. When the buffer contains only one fill_order object, when rolling out it, the skip flag in market_ticker_meta object didn't get updated to true, thus on next block , its volumes will be subtracted again if there is no new fill_order added into the buffer.

Usually there will be 2 fill_order objects on every fill, one taker and one maker. However, when GS happens, only a maker fill_order object will be created, but no taker. If there was only borrow position, there could be only one fill_order object in the buffer.

abitmore added a commit that referenced this issue Aug 6, 2019
abitmore added a commit that referenced this issue Aug 6, 2019

@abitmore abitmore moved this from To do to In testing in Feature Release (3.3.0) Aug 6, 2019

@abitmore

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

PR #1885.

@oxarbitrage

This comment has been minimized.

Copy link
Member

commented Aug 8, 2019

fixed by #1885

@oxarbitrage oxarbitrage closed this Aug 8, 2019

Feature Release (3.3.0) automation moved this from In testing to Done Aug 8, 2019

manikey123 added a commit to manikey123/bitshares-core that referenced this issue Aug 12, 2019
manikey123 added a commit to manikey123/bitshares-core that referenced this issue Aug 12, 2019
jmjatlanta added a commit that referenced this issue Sep 3, 2019
jmjatlanta added a commit that referenced this issue Sep 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.