Exiv2

That is not a legal JPEG. It is a deliberately corrupted file and we throw an exception. Not a bug.

501 rmills@rmillsmbp:~ $ exiv2 -pS http://dev.exiv2.org/attachments/download/1087/exiv2-oob-heap-Exiv2__Image__setIccProfile.jpg
STRUCTURE OF JPEG FILE: http://dev.exiv2.org/attachments/download/1087/exiv2-oob-heap-Exiv2__Image__setIccProfile.jpg
 address | marker       |  length | data
       0 | 0xffd8 SOI  
       2 | 0xffe2 APP2  |      16 | ICC_PROFILE.... chunk 0/0Exiv2 exception in print action for file http://dev.exiv2.org/attachments/download/1087/exiv2-oob-heap-Exiv2__Image__setIccProfile.jpg:
Failed to read image data
502 rmills@rmillsmbp:~ $ exiv2 -pa http://dev.exiv2.org/attachments/download/1087/exiv2-oob-heap-Exiv2__Image__setIccProfile.jpg
Warning: JPEG format error, rc = 5
http://dev.exiv2.org/attachments/download/1087/exiv2-oob-heap-Exiv2__Image__setIccProfile.jpg: (No XMP data found in the file)
503 rmills@rmillsmbp:~ $

Even with a corrupted JPEG you shouldn't read beyond the bounds of the allocated memory.

I've looked into the code, I think it's relatively trivial to fix, just have to check before the getULong that you can really read a long from that buffer. See attached patch.

r4653. Fixing GCC compiler warning. Add Hanno's test file to the test suite.

I've spent more time looking into this. I discovered (to my horror) that the command: $ exiv2 -pR test/data/exiv2-bug1247.jpg crashes on Windows when I use Hanno's patch. I could modify exiv2.cpp as follows:

void signalHandler(int signal)
{
    const char* reason = "!Access Violation!"; 
    std::cerr << "signalHandler " << signal <<" "<< reason << std::endl;
    throw std::exception(reason);
}

// *****************************************************************************
// Main
int main(int argc, char* const argv[])
try {
#ifdef EXV_ENABLE_NLS
    setlocale(LC_ALL, "");
    bindtextdomain(EXV_PACKAGE, EXV_LOCALEDIR);
    textdomain(EXV_PACKAGE);
#endif

    typedef void (*signalHandlerPointer)(int);

    signalHandlerPointer previousHandler = signal(SIGSEGV , signalHandler);

    // Handle command line arguments
   ... no changes to the rest of the code ...
    // Return a positive one byte code for better consistency across platforms
    return static_cast<unsigned int>(rc) % 256;
} catch ( std::exception& e ) {
    std::cerr << "std::exception " << e.what() << std::endl;
    return 99;
} // main

I'm not going to add this code to exiv2(.exe) and all the other sample applications at this time for 2 reasons:

1 It is very late in the Exiv2 v0.26 project.
2 This is a process mechanism. Adding signal handlers inside functions such as image::printStructure() or image::readMetadata() is tricky. We have to restore existing signal handlers when we return from those functions.

Perhaps a simpler approach is to write Image::lint() The function Image::lint() would call Image::readMetadata() and Image::printStructure() without modification. Image::lint() can be called by the ImageFactory to review an image. The function image::lint() can install/restore signal handlers.

I'm also wondering about a couple matters:

1) Why does the Mac/Clang report exceptions when cl/msvc signals? Perhaps clang converts signals to exceptions by default.

2) When I run tests in the Terminal/console, Windows displays asserts and signals as a dialog box. When I'm running the tests on the buildserver (jenkins), asserts and signals are reported in the transcript. How does it do that? Is there something we can set in a Windows process to cause this behaviour?

There is a major difference in signal/exception handling between GCC and Clang.

Clang:

1013 rmills@rmillsmbp-kubuntu:~/gnu/exiv2/trunk $ exiv2 -pa test/data/exiv2-bug1247.jpg 
Exiv2 exception in print action for file test/data/exiv2-bug1247.jpg:
Not a valid ICC Profile
1014 rmills@rmillsmbp-kubuntu:~/gnu/exiv2/trunk $ exiv2 -pR test/data/exiv2-bug1247.jpg  
STRUCTURE OF JPEG FILE: test/data/exiv2-bug1247.jpg
 address | marker       |  length | data
       0 | 0xffd8 SOI  
       2 | 0xffe2 APP2  |      16 | ICC_PROFILE.... chunk 0/0
      18 | 0xffffffffff (null)Exiv2 exception in print action for file test/data/exiv2-bug1247.jpg:
This does not look like a JPEG image      <---- This is an Exiv2 exception handler message
1015 rmills@rmillsmbp-kubuntu:~/gnu/exiv2/trunk $ 
1015 rmills@rmillsmbp-kubuntu:~/gnu/exiv2/trunk $ exiv2 -vVg svn -g compiler 
exiv2 0.25 001900 (64 bit build)
compiler=Clang
svn=4655
1016 rmills@rmillsmbp-kubuntu:~/gnu/exiv2/trunk $ grep "does not look" src/*.cpp
src/error.cpp:        {  3, N_("This does not look like a %1 image") }, // %1=Image type
src/error.cpp:        { 15, N_("This does not look like a JPEG image") },
src/error.cpp:        { 33, N_("This does not look like a CRW image") },
1017 rmills@rmillsmbp-kubuntu:~/gnu/exiv2/trunk $ 

GCC:

1017 rmills@rmillsmbp-kubuntu:~/gnu/exiv2/trunk $ exiv2 -pa test/data/exiv2-bug1247.jpg 
Exiv2 exception in print action for file test/data/exiv2-bug1247.jpg:                                                    
Not a valid ICC Profile                                                                                                  
1018 rmills@rmillsmbp-kubuntu:~/gnu/exiv2/trunk $ exiv2 -pR test/data/exiv2-bug1247.jpg                                  
STRUCTURE OF JPEG FILE: test/data/exiv2-bug1247.jpg                                                                      
 address | marker       |  length | data                                                                                 
       0 | 0xffd8 SOI                                                                                                    
       2 | 0xffe2 APP2  |      16 | ICC_PROFILE.... chunk 0/0                                                            
Segmentation fault (core dumped)     <--- segmentation fault                                                                                        
1019 rmills@rmillsmbp-kubuntu:~/gnu/exiv2/trunk $ exiv2 -vVg svn -g compiler 
exiv2 0.25 001900 (64 bit build)
compiler=G++
svn=4655
1020 rmills@rmillsmbp-kubuntu:~/gnu/exiv2/trunk $ 

I also discovered (on Stackoverlow) that you can hook the CRT to install your own report handler _CrtSetReportHook(). http://stackoverflow.com/questions/13943665/how-can-i-disable-the-debug-assertion-dialog-on-windows

This is interesting - however it requires modifying the code of the host application. That doesn't explain how Jenkins achieves this. Perhaps Jenkins hooks the CRT before using CreateProcess() to start a sub-process which inherits the hook. That doesn't seem likely to me. I think there's something in the process itself. Anyway, we don't need to solve this today. A search of the Jenkins source will reveal the necessary magic.