-m sometimes causes ExifTool to crash/hang

Started by Mac2, July 24, 2013, 10:16:47 AM

Previous topic - Next topic

Mac2

Windows platform, ExifTool command line application version 9.33.

Some users of my software have large TIFF files (200 MB to 600 MB), and some of these files caused ExifTool to hang for minutes and eventually crash.
I finally tracked this down to the -m command line parameter. Without it, the files are processed in a few seconds and the metadata is returned. With -m ExifTool does not return and crashes after a while (but responds to Ctrl+C on the command line).

Since my application has to deal with files containing all sorts of metadata produced by a wide range of applications and 20 years of image processing, I specify the -m parameter by default. My impression was that this causes ExifTool to process metadata (reading) also for files for which it otherwise would return errors or even abort. Or does this just affect how many problems ExifTool reports when it reads metadata from a file?

Phil, If you need the sample file (180 MB) say so and I will upload it somewhere and send you a link to your email address.

Phil Harvey

Upload a sample and I'll take a look.  My email is philharvey66 at gmail.com

-m only impacts the behaviour for [Minor] warnings/errors.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Mac2

Email sent.

Will removing -m cause more files to be rejected by ExifTool, or just more warning and error messages?

Phil Harvey

Adding -m should cause fewer files to be rejected.

I'll take a look at your file tomorrow when I'm back on fast internet.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Phil Harvey

Wel, I happened to go in to work for a different reason, so I took a look.

I will remove the [Minor] designation for IFD entries with a _really_ excessive count like this.  (Processing 27 million GPS IFD's uses enough memory to crash the Windows version, which is bad.)  So this problem should be fixed with the next release.  Also, for added protection, I will limit the processing to the first GPS IFD (there should only be one anyway).

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Mac2

QuoteProcessing 27 million GPS IFD's
Yikes! Either somebody was really busy adding GPS data or the file is corrupted real bad.

Thanks, Phil for the great support  :)

Could such a file being repaired by letting ExifTool rewrite all data?

Phil Harvey

The writer considers this a serious problem (there will be loss of data), so ExifTool can not be used to fix this problem because it will not write the image.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Mac2