eog crashed with SIGSEGV in do_rot_270()

Bug #960967 reported by Manuel dos Santos on 2012-03-21
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Eye of GNOME
Fix Released
eog (Ubuntu)
Tom Gall
Tom Gall
Tom Gall
libjpeg-turbo (Ubuntu)

Bug Description

Impact: it's not possible to save changes on some images

Test Case:
- download https://bugs.launchpad.net/ubuntu/+source/eog/+bug/960967/+attachment/2909708/+files/f%26a.jpg
- open it, rotate the image
- close eog
-> reply that you want to save that changes, that fails without the fix

Regression potential: should be limited, that just initialize datas


Impossible save picture.
After looking it, i try to close anq when i save, it crash ...

ProblemType: CrashDistroRelease: Ubuntu 12.04
Package: eog 3.3.92-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-19.30-generic-pae 3.2.11
Uname: Linux 3.2.0-19-generic-pae i686
ApportVersion: 1.94.1-0ubuntu2
Architecture: i386
CrashCounter: 1
Date: Wed Mar 21 09:48:37 2012
ExecutablePath: /usr/bin/eog
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012)
ProcCmdline: eog /home/User Name/Documents/scan\ hp/f&a.jpg
 Segfault happened at: 0x80a5819 <jtransform_execute_transform+265>: mov (%esi,%ecx,4),%eax
 PC (0x080a5819) ok
 source "(%esi,%ecx,4)" (0x65158272) not located in a known VMA region (needed readable region)!
 destination "%eax" ok
 Stack memory exhausted (SP below stack segment)
SegvReason: reading unknown VMA
Signal: 11SourcePackage: eog
 jtransform_execute_transform ()
 ?? ()
 eog_image_save_by_info ()
 ?? ()
 eog_job_run ()
Title: eog crashed with SIGSEGV in jtransform_execute_transform()
UpgradeStatus: Upgraded to precise on 2012-03-20 (0 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

visibility: private → public
description: updated
description: updated

 do_rot_270 (dst_coef_arrays=0x65158272, src_coef_arrays=0xb492b26c, y_crop_offset=349679729, x_crop_offset=470103840, dstinfo=0xb5d1ac50, srcinfo=0xb5d1aa6c) at transupp-8a.c:512
 jtransform_execute_transform (srcinfo=0xb5d1aa6c, dstinfo=0xb5d1ac50, src_coef_arrays=0xb492b26c, info=0xb5d1aa10) at transupp-8a.c:1475
 _save_jpeg_as_jpeg (image=<optimized out>, file=0xb4903fe0 "/tmp/eog-save-EWVIBW", error=0x8568d4c, source=<optimized out>, target=<optimized out>) at eog-image-jpeg.c:324
 eog_image_save_by_info (img=0xb4917800, source=0x8539d50, error=0x8568d4c) at eog-image.c:1864
 eog_job_save_run (ejob=0x8568d40) at eog-jobs.c:643

Changed in eog (Ubuntu):
importance: Undecided → Medium
summary: - eog crashed with SIGSEGV in jtransform_execute_transform()
+ eog crashed with SIGSEGV in do_rot_270()
tags: removed: need-i386-retrace
Vadim Rutkovsky (roignac) wrote :

Could you please attach the picture you were trying to save and specify which transformations did you perform (if any)

Changed in eog (Ubuntu):
status: New → Incomplete

I open the picture and i rotate it ... after i try to close and save it ... so it crach !!!

The picture is a scan from my hp photosmart c3130 ...

here is the picture ...

Changed in eog (Ubuntu):
status: Incomplete → New
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in eog (Ubuntu):
status: New → Confirmed
affects: eog (Ubuntu) → libjpeg-turbo (Ubuntu)
affects: libjpeg-turbo (Ubuntu) → libjpeg8 (Ubuntu)
affects: libjpeg8 (Ubuntu) → libjpeg-turbo (Ubuntu)
Tom Gall (tom-gall) on 2012-04-19
Changed in libjpeg-turbo (Ubuntu):
assignee: nobody → Tom Gall (tom-gall)
Tom Gall (tom-gall) wrote :

Thanks much for the test image and bug report. I'm able to recreate the issue locally.

In my case it's not crashing, I get an error message on the save that indicates "Maximum supported image dimension is 65500"

I have used jpegtran (a command line tool part of libjpeg-turbo-tools and rotated the image successfully with that, I believe that rules out that the original image has any errors.

I am using a newer libjpeg-turbo8 (found in ppa:linaro-maintainers/staging-overlay) which I'm intending to release as an update in the archive soon.

Will gdb a bit with eog, I am concerned given the error message about image sizes, that there is garbage in the image header after the rotation and that's the bug, not libjpeg-turbo attempting to save the image.

Tom Gall (tom-gall) wrote :

Ok so looking into this. When the app crashed, is not from libjpeg-turbo8 instead it's from http://bazaar.launchpad.net/~vcs-imports/eog/trunk/view/head:/jpegutils/transupp-8a.c which is a file that was copied some years back from the libjpeg project.

Why this app has internal copies of these files instead of just making use of the same routines which are also provided by libjpeg-turbo is for others to answer.

Running eog in gdb looking at _save_jpeg_as_jpeg in the eog code

 jpeg_stdio_src (&srcinfo, input_file);

 /* Enable saving of extra markers that we want to copy */
 jcopy_markers_setup (&srcinfo, JCOPYOPT_DEFAULT);

 /* Read file header */
 (void) jpeg_read_header (&srcinfo, TRUE);

 /* Any space needed by a transform option must be requested before
  * jpeg_read_coefficients so that memory allocation will be done right.
 jtransform_request_workspace (&srcinfo, &transformoption);

 /* Read source file as DCT coefficients */
 src_coef_arrays = jpeg_read_coefficients (&srcinfo);

 /* Initialize destination compression parameters from source values */
 jpeg_copy_critical_parameters (&srcinfo, &dstinfo);

 /* Adjust destination parameters if required by transform options;
  * also find out which set of coefficient arrays will hold the output.

--- FINE
 dst_coef_arrays = jtransform_adjust_parameters (&srcinfo,

 /* Specify data destination for compression */
 jpeg_stdio_dest (&dstinfo, output_file);

 /* Start compressor (note no image data is actually written here) */
 jpeg_write_coefficients (&dstinfo, dst_coef_arrays);

by jpeg_stdio_dest, in dstinfo the jpeg_width and jpeg_height portions of the structure have garbage in them. And just after the jpeg_copy_critical_parameters those fields are fine.

debug continues. Theory at this point, the old and copied jtransform_adjust_parameters might contain the bug.

Tom Gall (tom-gall) wrote :

further in jtransform_adjust_parameters (which is in the old jpeg copied code, not in the libjpeg-turbo library)

it makes a call to transpose_critical_parameters

Before that function, it's fine, after the noted fields jpeg_width & jpeg_height in dstinfo have garbage in it.

quite close now.

Tom Gall (tom-gall) wrote :

The fix is two parts. (1 - an upgrade to libjpeg-turbo (which I am doing regardless) and this patch to eog.

The fix in the enclosed patch is simple, the data structure info in init_transform_info() isn't being zeroed out. Since the whole point of init_transform_info() is to init the info structure passed into it, this is problematic and ultimately was causing the corruption of the jpeg headers for the file to be saved in _save_jpeg_as_jpeg

Tom Gall (tom-gall) wrote :

EOG guys, this is a fix to your code, please take, apply and shepherd upstream.

affects: libjpeg-turbo (Ubuntu) → eog (Ubuntu)
Changed in eog (Ubuntu):
status: Confirmed → In Progress
Tom Gall (tom-gall) wrote :

For the impatient, ppa:tom-gall/packages has an updated eog debs with the fix applied.

The attachment "03_initjpegtransform.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Matthias Klose (doko) wrote :
Changed in libjpeg-turbo (Ubuntu Precise):
importance: Undecided → Medium
milestone: none → precise-updates
status: New → Triaged
Changed in eog (Ubuntu Precise):
milestone: none → precise-updates
Felix Riemann (friemann) wrote :

Hi Tom,

I stumbled over your patch by googling the maximum image dimensions error message and I pulled it into our git:
Thanks for investigating this.

Btw, we had to integrate the transupp.{c,h} files as these routines are not exported by libjpeg.

Changed in eog:
importance: Unknown → High
status: Unknown → Fix Released
Changed in eog (Ubuntu):
status: In Progress → Fix Committed
Changed in eog (Ubuntu Precise):
status: In Progress → Fix Committed
description: updated
description: updated

Hello Manuel, or anyone else affected,

Accepted eog into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/eog/3.4.2-0ubuntu1 in a few hours and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: added: verification-needed
Chris Halse Rogers (raof) wrote :

I've accepted this into precise-proposed, as it seems to be fixed upstream and that should make it into Quantal. Please make sure that the Quantal task's status is correct - we won't be moving it into precise-updates until it's clear that it's being fixed in Quantal, too.

Sebastien Bacher (seb128) wrote :

the new eog works fine, setting as verified

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eog - 3.4.2-0ubuntu1

eog (3.4.2-0ubuntu1) precise-proposed; urgency=low

  * New upstream version
    - Refuses to save file after horizontal flip (lp: #960967)
 -- Sebastien Bacher <email address hidden> Wed, 13 Jun 2012 22:13:38 +0200

Changed in eog (Ubuntu Precise):
status: Fix Committed → Fix Released
Scott Kitterman (kitterman) wrote :

I missed the note about not moving to -updates until it was clear this was being fixed in quantal. I've milestoned the bug so we don't forget.

Changed in eog (Ubuntu):
milestone: precise-updates → ubuntu-12.10-beta-1
Kate Stewart (kate.stewart) wrote :

cleaned up the milestoning (targeting to precise-updates for quantal didn't make sense). Targetted this to the quantal release for tracking.

Changed in eog (Ubuntu Quantal):
milestone: ubuntu-12.10-beta-1 → ubuntu-12.10-beta-2
Changed in libjpeg-turbo (Ubuntu Quantal):
milestone: precise-updates → ubuntu-12.10-beta-2
Rolf Leggewie (r0lf) wrote :

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

Changed in eog (Ubuntu Quantal):
status: Fix Committed → Won't Fix
Changed in libjpeg-turbo (Ubuntu Quantal):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.