AssertionError item_type == subclass.ITEM_TYPE #17
Comments
|
The relevant binary data The initial assertion error occurs at position 2bb, which is the second As you can see, that After the |
|
What I'm not too sure about is the semantics I guessed about the byte following the assertion error. In this case its value is 3, which (coincidentally?) corresponds with the expected item_type. However, what I noticed is that 3 is also the block_type for I think that would make a little bit more sense as well, but it's hard to tell given I only have one example. It simplifies the code by quite a lot too. |
|
Also, I don't have a solution yet for the block length error, but I wanted to get the important parts sorted out first. |
|
Thanks for reporting!
Are you sure about where the assertion is happening? The data you posted looks ok to me: Which seems to match the SceneGlyphItemBlock values of Anyway it would be good to improve error handling during parsing, so that an error is reported for the block where the problem occurs, but the rest of the file can continue to be parsed. |
|
If I misread the binary data I'll have to take a closer look again. The code does think the block is a SceneLineItemBlock, not a SceneGlyphRangeBlock. The binary data I posted doesn't show that there are two block headers immediately following one another, the first is of course relevant. The second one is what is shown in the post I made, the second is indeed correct as that is what I end up parsing with the recursive call to SceneItemBlock. I'll post more context of the binary data since I obviously missed something. |
|
Here's the same binary data with more context As you can see, this starts with a block of type Looking at it again, it seems more reasonable that this block simply doesn't have any data. How that is supposed to work, I'm not sure. Given the reported subblock length = 0, the code assumes a subblock definition is followed by a byte Given the subblock has a length of 0, it could be the case that it is a similar scenario as the the previous issue/PR I worked on, that when data is removed, the binary data gets rid of some bytes (presumably to save some space?) assuming the block's presence is not a bug. Following this hypothesis, I reverted back my changes and use this simpler code ...
deleted_length = stream.read_int(5)
if stream.has_subblock(6):
with stream.read_subblock(6) as block_info:
# checking block size
if block_info.size > 0:
item_type = stream.data.read_uint8()
assert item_type == subclass.ITEM_TYPE
value = subclass.value_from_stream(stream)
else:
value = None
# Keep known extra data
extra_data = block_info.extra_data
else:
value = None
extra_data = b""I get a This leads me to believe this block is simply kaput. The subblock header is five bytes if I understand it correctly, a tag which is one byte, 0x6c followed by 4 byte integer specifying the size of the subblock. It is not unlikely this is a bug on ReMarkable's side if I'm correct, this block simply shouldn't exist. It is a SceneLineItemBlock containing a subblock header lacking any further data, also reporting the incorrect length. The block does end at 698, as a regular well-behaving block starts at 699 (0x2bb) which you pointed out as well. |
|
Ok, I think the problem is that the I think probably the solution is to make |
|
That makes a lot of sense, although I'm still a little bit confused about what the purpose is of an empty block. |
|
The empty blocks occur when something has been deleted. The deleted item id information is kept so that editing conflicts can be resolved, but the deleted data is not kept. You can tell that it's a deleted item because the deleted_length (tagged |
|
I made a PR where I abort checking the subblock if the |
Back again with another error!
This one is a bit more difficult to figure out, but I feel like I got a decent idea about what's approximately going on.
Error
Alright, so we have a
SceneItemBlockwhere the readblock_info item_typedoesn't match up with thesubclass.ITEM_TYPEIE, this:
The read item_type in this case was 1, whereas the subclass.ITEM_TYPE is 3. So we have a subclass of
SceneLineItemBlock, but theitem_typeof the subblock corresponds to aSceneGlyphItemBlock.What I found in the .rm file is that there's a singular byte immediately following the read item_type which contains the expected item type (at least, in this scenario? Maybe it doesn't always match up?), so I modified the code to read that byte when the assertion fails.
Next, I found that the
override_item_typewas followed up by four IDs and an int, so clearly that has to be a block.My guess is that somehow a block ends up becoming another block. What exactly's going on, I'm not super sure yet.
So I recur to read the block again, starting after the
override_item_type.This works fine up until the point of trying to read the subclass' value in
value_from_stream. This makes sense, since our subblocks' item_types weren't matching up. So my guess was that we ended up here with aSceneLineItemBlockwith aGlyphRangesubblock. Again, I'm not sure how that makes sense but it does look like it's what's happening here.So I modify the code a bit more again, to override what reader class is getting used. Instead of determining the block subclass by
block_typeinSceneItemBlock, I use theitem_typeas read in the second (recur) call toSceneItemBlocksubblock to determine the subclass. The code is a bit ugly but as far as I can see this does work as you would expect, no more parsing errors after this, making the code look like this:I do have one exception left:
Which makes sense since I read two blocks worth of data but I report only one block's length.
The text was updated successfully, but these errors were encountered: