You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
** Expected Behavior**
When printing a range tree for a large metaslab, proper offsets should be prrinted for every segment.
** Actual Behavior**
Range segments appeared to increase, then reset back down to the starting value, and this repeated over and over. The last range seg was printed by the pretty printer as [0x324fff4ca00 0x324fff68600) (length 0x1bc00). However, the last range seg (as retrieved by walking the btree directly, and printing out the elements manually) had rs_start = 33552997. When shifted by 9 and added to the ms_start (0x32400000000), it should have been [0x327fff4ca00 0x327fff68600) (length 0x1bc00)
Steps To Reproduce the Problem
Create a pool on disks large enough to contain metaslabs larger than 4 GiB, allocate some space on the pool, and look at the ms_allocatable trees.
Additional Context
It's not clear to me why this occurs; tests in python3's repl don't show similar behavior:
>>> x = 33552997
>>> y = 9
>>> z = 3453153705984
>>> start = (x << y) + z
>>> print("{:x}".format(start))
327fff4ca00
It may have something to do with the way drgn represents integers internally.
The text was updated successfully, but these errors were encountered:
pcd1193182
changed the title
"06/18/2020 range_tree pretty printer drops high bits of start << shift calculation"
06/18/2020 range_tree pretty printer drops high bits of start << shift calculation
Jun 19, 2020
** Expected Behavior**
When printing a range tree for a large metaslab, proper offsets should be prrinted for every segment.
** Actual Behavior**
Range segments appeared to increase, then reset back down to the starting value, and this repeated over and over. The last range seg was printed by the pretty printer as
[0x324fff4ca00 0x324fff68600) (length 0x1bc00)
. However, the last range seg (as retrieved by walking the btree directly, and printing out the elements manually) hadrs_start = 33552997
. When shifted by 9 and added to thems_start
(0x32400000000), it should have been[0x327fff4ca00 0x327fff68600) (length 0x1bc00)
Steps To Reproduce the Problem
Create a pool on disks large enough to contain metaslabs larger than 4 GiB, allocate some space on the pool, and look at the ms_allocatable trees.
Additional Context
It's not clear to me why this occurs; tests in python3's repl don't show similar behavior:
It may have something to do with the way drgn represents integers internally.
The text was updated successfully, but these errors were encountered: