Exiv2

Thank you Alyssa for reporting the crash.

Indeed it is a quite a notorious bug.
I will look into the matter asap and patch the video code accordingly.

Hi Alyssa,
I looked into the problem, and this is what I observed. Please correct me if I may have missed some point.

The file that you provided with the issue seems to have been generated manually. (I really appreciate the effort.)
But it seems that the file doesn't follow the RIFF standard specification.

I am saying this, because when I run the exiv2 utility while debugging the Video File, this is what I got as the size.

Tag = NCDT
Size = 153428472

The size is not turning out to be zero, as such.
I guess this is the reason for the long run of the loop that you specified, "and will loop for a very long time".
This simply means that it is trying to subtract 4 recursively from the size, and will definitely take time.

I guess this problem should not occur, if the file has proper fields according to the RIFF standards.

Please can you send a link or upload a proper RIIF or ASF file which would produce a similar effect.

Sorry, if you don't care about bugs caused by invalid data, these bugs are irrelevant. That's why I said "I don't know if you care about these kind of bugs". Various projects are using libexiv2 right now for reading metadata on files which may have been downloaded from the internet, for example, so trusting input files sounds like a bad idea.

Thanks for reporting this issue, Alyssa. We do care about such things; making sure Exiv2 behaves well for any kind of input is a challenge that we have accepted. We have many checks to avoid issues with corrupted (or 'doctored') images in the more mature code and we'll be happy to add more. The video metadata support on the other hand is relatively new and has not been exposed to as many problematic files, so it may not be quite as stable.

Abhinav, see e.g., tiffvisitor.cpp for examples of sanity checks and how they are typically handled. Generally, if we detect an anomaly, we issue a warning, make sure the process doesn't fail (e.g., by skipping the suspicious section) and continue parsing as much of the remaining metadata as possible. Below is an example from this file. Without having looked at the reported case in detail, it sounds like a similar check might be possible to avoid processing unreasonably large values and avoid the reported issue(s). As you program more, it will become a reflex to consider "what if" scenarios and document your assumptions (e.g., using assert) in your code routinely, so that many such cases (never all) will be taken care of from the beginning.

        // Sanity check with an "unreasonably" large number
        if (n > 256) {
#ifndef SUPPRESS_WARNINGS
            EXV_ERROR << "Directory " << groupName(object->group()) << " with " 
                      << n << " entries considered invalid; not read.\n";
#endif
            return;
        }

Thank you Alyssa and Andreas for your valuable feedback.
I will fix the errors asap.