Exiv2

I'm even more confident that it's exvGettext() that is causing this. When I configure and build with --disable-nls, the problem goes away. When NLS is disabled, exvGettext() is compiled as:

const char* exvGettext(const char* key)
{
    return key;
}

Hi Robin, Henrique,

Robin Mills wrote:

I'm even more confident that it's exvGettext() that is causing this. When I configure and build with --disable-nls, the problem goes away. When NLS is disabled, exvGettext() is compiled as:
[...]
No more mysterious calls into dgettext. Being a native English speaker, I don't have a strong feel for localization. However I don't see a need to localize XMP keys.

I took the sample file and was able to reproduce the bug on my Linux Machine as well.
I tried to do away with all the exvGettext(), but it didn't solve the problem for me.

So I took the problem a little deeper and saw what was being fetched in the XMP container.

The program was getting stuck because the data to be read was too large for the buffer allocated. The default size of the buffer was 100, and the data that was to be read was 8192 in size.

infoSize :8310   8310
infoTagsHandler :DTIM
infoSize :20
before :20
after :20Data : 2012:01:01 00:07:14Size : 8278
true for label Xmp.video.DateTimeOriginal
Info Tag Xmp.video.DateTimeOriginal       infoData :2012:01:01 00:07:14
infoTagsHandler :IKEY
infoSize :8192
before :8192
after :8192Data : Size : 78
true for label Xmp.video.PerformerKeywords
Info Tag Xmp.video.PerformerKeywords       infoData :
infoTagsHandler :ISFT
infoSize :60
before :60
after :60Data : EASTMAN KODAK COMPANY KODAK EASYSHARE Sport Camera, C123Size : 10
true for label Xmp.video.Software
Info Tag Xmp.video.Software       infoData :EASTMAN KODAK COMPANY KODAK EASYSHARE Sport Camera, C123
infoTagsHandler :SRAT
infoSize :2
before :2
after :2Data : Size : 0Exit and runReached the DECODE BLOCK
JUNK
Reached the DECODE BLOCK
LIST
Reached the DECODE BLOCK
movi

When I looked into the data of the file closely, it was a bit clear where the potential problem was lying.
On looking at the data of the TAG - IKEY, it seemed strange that the data was out of range.

infoTagsHandler :IKEY
infoSize :8192
before :8192
after :8192Data : Size : 78
true for label Xmp.video.PerformerKeywords
Info Tag Xmp.video.PerformerKeywords       infoData :

Generally it is supposed to have a few words as information, but the size of the TAG in this file was exceptionally large, and at the same time, empty.

For now I would be inserting this buffer overflow fix.

@Robin,
You are absolutely right about fixing the issue with exvGettext(), as it may not be always safe to call it.

Please do tell me what is your opinion on this issue as of now. Does it seem fixed..?

I think it would be best if I change the code in the places where exvGettext() has been used, for the following reasons -
[a] It is mostly used in Video code which has been written by me.
[b] I have a lot of video files at my home PC which I can use to test and verify that all changes have been done without breaking the previous working of the code.

Hello,

If needed i can try to use the code in multiple videos files as well. That is the most i can do, not much help with the code!

I did run exiv2 in all my videos files before to find this problem.

Henrique and Abinhav

Thank You both for your work on this. We're close to resolving this.

@Henrique
There were bugs reported with DigiKam <-> Exiv2 crashing (#961 and #963). These were in the exception handler in libkexiv2 (the sandwich between DigiKam and Exiv2). That part of the code has been made more robust. So, it's been fixed and DigiKam won't crash here any more. The fix isn't part of Exiv2. I've no idea how/when it willl appear in DigiKam.

However, it's only the crash that has been fixed. You will still not be able to open this file. I think we'll resolve that puzzle in the next few days.

@Abhinav
Thanks very much for offering to undertake the fix. I think you've discovered the real issue here. There is a buffer overflow. For sure you know more about this code. It sounds as though the overflow is being caused by the file containing erroneous data and 8000 bytes are traveling a road designed for less that 100 bytes. I encourage to find a fix which prevents the overflow by chopping the data (say after 90 bytes), or throw an Exiv2 exception.

I think my concerns about exvGettext() are probably a lucky, but bad, guess and do not deserve further investigation/attention at the moment.

@Henrique and Abhinav
I think it's very helpful that you have loads of test files. When we get this fixed, please run every test you can. You cannot perform "too much testing!".

Robin

Hi Henrique,
Shall we close this bug now..??

Can you please confirm if this got fixed at your end as well..?

Hi Abhinav Badola,

Sorry but the error persists for me

*** Error in `digikam': malloc(): memory corruption (fast): 0x00007ffcb802f370 ***
<pre>

And i keep geting weird errors.

Problem is i am not using the latest digikam!

I still with 4.2.

Rigth now i can't do more debuging or testing... i don't even have time to fix my just broken digikam again.

Sorry =/

Hi Henrique,

Are you building digiKam from source..?
Or are you using some distribution of digiKam..?

Hello,

I am using it from distro.
Manjaro or Arch

I think manjaro update it to lastest. So i might be able ot test it later today!
But at the end of the week i will test with digikam 4.5

Hi Henrique,

I would like to inform you that this bug won't get fixed even after you update digiKam to the latest.

The fix is currently in our trunk (i.e. main development svn repository).
If you install digiKam with default packages, it will use the older version of Exiv2, i.e. 0.24

The fix to your specific bug will be shipped in the next version of our library.(0.25)

To fix digiKam for the time being, you will have to manually install the latest version of Exiv2 from the svn repository.

It is pretty easy to install Exiv2 as it only depends on very few C++ libraries, and most of them are part of Standard C++ Libraries for development. The below links can help you get started with installing the latest version of Exiv2.
[1] http://www.exiv2.org/download.html
[2] http://dev.exiv2.org/projects/exiv2/wiki/How_do_I_build_Exiv2_on_the_XYZ_platform

Henrique Fernandes wrote:

Hello,

I am using it from distro.
Manjaro or Arch

I think manjaro update it to lastest. So i might be able ot test it later today!
But at the end of the week i will test with digikam 4.5

Hi Abhinav,

Thanks for the info, but one reason that i am usign arch now if to get up to date packages from repository.
When in ubuntu i always had to updatd packages by hand and for security fix and etc this way doesn't work well.

But still, i am glad to see it was fixed. I will simple remove this video file from my library, later on i can put it in again!

So if you know 0.25 fixed the issue you can close the ticket. The only video i have that gives me any errors is the one i uploaded here!

Thanks!