Bug 17746

Testing MGA5 x64 real h/w: OK

Curiosity: Despite already having and using occasdionally EOG, I did not have lib64eog-gir3.0 . I installed it for the update, but clearly it is not being used here.

Updated to: lib64eog-gir3.0-3.14.3-1.1.mga5      eog-3.14.3-1.1.mga5

Viewed a mixed bag of image types, fullscreen, slideshow, all seems OK.

CC: (none) => lewyssmith
Whiteboard: (none) => MGA5-64-OK

mga5  i586 in virtualbox  Mate

Before updating ran a check on a large PNG file (27000x27000).
The image displayed for several seconds then vanished:
[lcl@cursa ~]$ eog big.png
**
Gdk:ERROR:gdkcairo.c:193:gdk_cairo_surface_paint_pixbuf: assertion failed: (cairo_image_surface_get_format (surface) == CAIRO_FORMAT_RGB24 || cairo_image_surface_get_format (surface) == CAIRO_FORMAT_ARGB32)
Abort

Performed the update and tested eog against several different image types.  Used the image and display manipulation functions, ran the slideshow and edited preferences to alter the period.  Everything working fine except with the 27000x27000 PNG image.  It rendered alright but crashed after 4 or 5 seconds.  That looks similar to bug #17739 which was fixed for eom.  The current problem manifests itself on x86_64 as well.

However eog looks good for this update.

CC: (none) => tarazed25

Sorry, I have to retract that.  Somehow overlooked the point of the update.  The big.png test is the PoC and shows that the update does not fix the problem.

Keywords: validated_update => (none)

@Lewis.  And apologies to you also - I am going to have to cancel the 64bit OK.

After updating eog and lib64eog-gir3.0:
[lcl@vega ~]$ eog big.png

(eog:2269): Gdk-WARNING **: eog: Fatal IO error 2 (No such file or directory) on X server :2.

eog tried to render the image but failed after a few seconds.  The point of failure looks different from that encountered in the 32bit test so may well be a different bug.  Shall file a new bug against it with an strace and see what transpires.

All other tests succeed so I am in a bit of a quandary about the status of this update for 64bits.  Has the original bug been squashed or not?  Safer to let it stand.

(In reply to Len Lawrence from comment #4)
> @Lewis.  And apologies to you also - I am going to have to cancel the 64bit
> OK.
Quite agree. You have done a marvelous job here, much more thorough than mine. I overlooked the "memory allocation integer overflow in gdk_cairo_set_source_pixbuf on large pixbufs" issue. Well dug out.
 http://openwall.com/lists/oss-security/2016/02/10/6 ->
 https://bugzilla.gnome.org/show_bug.cgi?id=703220
Not sure about whether whether to let this bug stand 'awaiting feedback' i.e. another correction; or squash it until that correction arrives, new bug. David will know.

Created attachment 7462 [details]
Large image used for eom and eog tests

Bug https://bugs.mageia.org/show_bug.cgi?id=17778 filed for the error report noted in comment #4.

So how do the outputs/traces compare before and after the update?  Is there a difference between 32-bit and 64-bit?

Only one of the tests has an strace file.
Terminal output:
i586 VM
Before update:
**
Gdk:ERROR:gdkcairo.c:193:gdk_cairo_surface_paint_pixbuf: assertion failed: (cairo_image_surface_get_format (surface) == CAIRO_FORMAT_RGB24 || cairo_image_surface_get_format (surface) == CAIRO_FORMAT_ARGB32)
Abort

Afterwards:
(eog:2269): Gdk-WARNING **: eog: Fatal IO error 2 (No such file or directory) on X server :2.


x86_64 both before and afterwards:
(eog:30041): Gdk-WARNING **: eog: Fatal IO error 2 (No such file or directory) on X server :2.0.

For x86_64 I had no record of the before update message so downgraded and  tried the test again and found the same behaviour.

Tried this for the before update version on 64-bit hardware:
[lcl@vega ~]$ gthumb big.png
(gthumb:31361): Gtk-WARNING **: Failed to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files

(gthumb:31361): Gtk-CRITICAL **: gtk_widget_set_visible: assertion 'GTK_IS_WIDGET (widget)' failed
Segmentation fault

which makes me wonder if things might be different on the GNOME desktop.
Off to try that....

Thanks for the confirmation, that's the results that I expected.  I would expect this overflow to only reasonably be able to be triggered on 32-bit, and you showed that it is fixed, but uncovered another bug.  It'd be helpful to know if the new bug you uncovered still exists in Cauldron.

Going native had no effect on x86_64.  i.e. The error message was the same for eog.  So that is an OK for 64-bit systems.
Thanks for the clarification David.

Sorry David.  I don't have a Cauldron installation any more.  I was thinking of taking a break and rebuilding it.  Will report back on one of the mailing lists unless somebody beats me to it.

I might as well report it here as well.  Cauldron installed:
eog-3.19.90-1.mga6
This displays the big.png but without the window frame and menu and it crashes after several seconds with -
(eog:8426): Gdk-WARNING **: eog: Fatal IO error 2 (No such file or directory) on X server :0.

So the bug has propagated to later versions.
eom faults in the same way after successfully displaying the image (with the window decorations in this case).
$ eom big.png
eom: Fatal IO error 2 (No such file or directory) on X server :0.

I shall run an strace in the morning and add this report to bugzilla.
Middle of the night here.

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2016-0074.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED