-
Notifications
You must be signed in to change notification settings - Fork 47
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
Move the element size check in EbmlCallbacks #273
base: master
Are you sure you want to change the base?
Conversation
4dad849
to
1c12964
Compare
Unfortunately these changes cause aborts due to failed assertions when reading data from damaged files:
This is the same old topic: reading invalid files must not abort the process (be strict in what you write/produce but lenient in what you read/accept). |
The assert is not there to break on bogus files, but to double check on the coherence of the code. The code that creates Result is probably correct. But it probably has an "infinite" size which is not handled in that test. I'll do a fix. |
And thanks for testing this (and the rest) by the way. I need to finish porting mkvalidator and mkclean as I would probably have caught it earlier. |
0a9e927
to
62962c0
Compare
@mbunkus can you check with this new version ? Now the size needs to check if this a finite or infinite size value. The code behavior should be the same as before. Finite size elements with a bogus size were not accepted before (created by then discarded). If it still fails, can you share the file ? |
A small ask for the future: when you publish PRs in libEBML for which a corresponding change is required in libMatroska, please post in the libEBML PR the number of the libMatroska PR & vice versa. Makes it much easier for me to go through all of those changes. Thanks! |
After testing your updated changes, reading certain damaged files still aborts with failed assertions:
This is the file from above, but I have others. |
Can you please re-base on current master? I'll give it another try afterwards. Thanks. |
So it can be checked even before the element is created.
CreateElementUsingContext() never creates an element with an invalid size.
We get that information from the EbmlCallbacks.
I rebased the code but did not do any further investigation. |
Implements #272
And so we can check the validity of the size before an element is created.