Bug #1146

Crash when saving a rotated JPG image

Added by Uwe Klotz almost 2 years ago. Updated almost 2 years ago.

Status:ClosedStart date:27 Dec 2015
Priority:NormalDue date:
Assignee:Robin Mills% Done:

100%

Category:tiff parserEstimated time:2.00 hours
Target version:0.26

Description

Rotating and saving a JPG image in gthumb (see attachment) results in a crash:

gthumb: tiffcomposite.cpp:749: virtual Exiv2::Internal::TiffComponent* Exiv2::Internal::TiffMnEntry::doAddPath(uint16_t, Exiv2::Internal::TiffPath&, Exiv2::Internal::TiffComponent*, Exiv2::Internal::TiffComponent::AutoPtr): Assertion `mn_' failed.
Aborted (core dumped)

exiv 0.25
gthumb 3.4.1
Fedora 23 x86_64

See also:
https://bugzilla.gnome.org/show_bug.cgi?id=759908

CIMG2598.JPG - Example image (1.23 MB) Uwe Klotz, 27 Dec 2015 19:31

libexiv2.so.14.0.0 (4.56 MB) Robin Mills, 28 Dec 2015 18:55


Related issues

Related to Exiv2 - Bug #1106: Crash in exiv2 due to assertion when setting rating on jp... Closed 19 Aug 2015

History

#1 Updated by Robin Mills almost 2 years ago

Can you explain a little more about this, please? The image you've sent is OK.

1) Does it crash in some tool in Gnome when you rotate it? Which tool?
2) Have you been able to rotate it? Yes, I understand that it crashes, however it may have been correctly rotated.

#2 Updated by Uwe Klotz almost 2 years ago

Robin Mills wrote:

Can you explain a little more about this, please? The image you've sent is OK.

1) Does it crash in some tool in Gnome when you rotate it? Which tool?
2) Have you been able to rotate it? Yes, I understand that it crashes, however it may have been correctly rotated.

gthumb crashes each time when I try to save an image (after rotating, resizing, ...) from this particular camera. Only after clearing the Exif data those images can saved. Saving the image is the operation that causes the crash, independent of the previous operations.

#3 Updated by Robin Mills almost 2 years ago

  • Category set to tiff parser
  • Assignee set to Robin Mills
  • Target version set to 0.26

Thanks for the clarification. I'll investigate tomorrow.

#4 Updated by Robin Mills almost 2 years ago

  • File libexiv2.so.14.0.0 added
  • Status changed from New to Assigned
  • % Done changed from 0 to 80
  • Estimated time set to 2.00

Uwe

Thank You for letting me know about this. There is something wrong with the 'vanilla' 0.25 in use. I installed gThumb and everything seemed fine. However I am using /usr/local/lib/libexiv2.so.14.0.0 which is my private build from last week.

I replaced the private build with a 'vanilla' build of v0.25 and it crashed. I am surprised, because I can't think of any changes that may have fixed this. And I don't know what has caused it either!

I download last night's linux build from our buildserver and that seems to be OK. I attach the library. Can you try this? I hope you'll be happy! You install this with:

sudo cp libexiv2.so.14.0.0 /usr/local/lib

You can get builds of Exiv2 (latest, daily, weekly, monthly, by platform etc) from: http://exiv2.dyndns.org:8080/userContent/builds/Categorized/Latest/

#5 Updated by Uwe Klotz almost 2 years ago

Thanks for taking care, Robin! I tried the workaround you proposed and it works, no crash.

It would be nice to get an official fix version from Red Hat/Fedora, but I don't know where and how to address this.

#6 Updated by Robin Mills almost 2 years ago

  • Status changed from Assigned to Feedback
  • % Done changed from 80 to 100

Uwe

That's wonderful. I don't know how/when the Linux folks refresh their libraries. I'm surprised by this, and very happy that we have a solution.

Robin

#7 Updated by Robin Mills almost 2 years ago

I think it's unlikely that the Linux people will do anything about this until mid-2016. We expect to ship v0.26 in spring (April or May) and that will arrive on the Linux platform some time later.

It's most unlikely that they would take code from our trunk and put it on the platform. In fact, I would be shocked if they did that as the trunk is for development, not deployment. Having said that, we have a good test suite that is run by our buildserver when code is submitted. So our trunk is usually stable and useable. None-the-less, I would be very surprised if they were to randomly take code from our trunk and put it on the platform.

The open-source community have achieved remarkable results. However, for me at least, working on open source is a lonely business with almost no communication with other members of the community.

Before I retired, I worked for Adobe in Silicon Valley, California. I have a mental image that Linux is like Adobe with thousands of engineers working together and emailing each other day and night. However, for me working on Exiv2 in England, it's a lonely business.

I recommend that you update bugzilla with this result. I'll be surprised if they do anything about this until we ship v0.26.

#8 Updated by Andreas Huggel almost 2 years ago

The sample image has a Casio2 makernote: this issue is most likely a duplicate of #1106.

#9 Updated by Robin Mills almost 2 years ago

You are 100% correct, Andreas (nothing unusual about that). I was off working on our building project when you dealt with that matter.

Right. That solves the puzzle of what has caused this issue with v0.25 AND solves the puzzle of why a build from the trunk has fixed it.

Well done, Andreas. I hope you're having a great break over "The Holidays".

#10 Updated by Robin Mills almost 2 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux