eog crashed with SIGSEGV in do_rot_270()

StacktraceTop:
 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

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

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 ...

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

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.

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,
       &dstinfo,
       src_coef_arrays,
       &transformoption);

--- NOT FINE
 /* 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.

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.

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

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

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.]

Hi Tom,

I stumbled over your patch by googling the maximum image dimensions error message and I pulled it into our git:
http://git.gnome.org/browse/eog/commit/?id=11f05ec911b4208faa8f00ecd9f4830ca39fcb25
Thanks for investigating this.

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

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!

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.

the new eog works fine, setting as verified

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

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.

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

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".

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release