GNOME Bugzilla – Bug 441443
jpeg loader does not set error upon abortion
Last modified: 2010-07-10 04:07:00 UTC
If the jpeg-loader is stopped while loading is not finished FALSE is returned by its stop_load function. But it doesn't set an error. That leads to a critical warning: GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed It's reproducable by using a GTK-2.11 configured EOG 2.19.x/trunk to quickly skip through a series of jpeg images. The message is triggered in this block in gdk_pixbuf_loader_close: GError *tmp = NULL; if (!priv->image_module->stop_load (priv->context, &tmp) || tmp) { g_propagate_error (error, tmp); gdk_pixbuf_loader_ensure_error (loader, error); retval = FALSE; }
Created attachment 88883 [details] [review] Supply the current GError for fatal_error_handler
Looks correct. Please commit on both branches.
Committed to trunk r17989 and 2.10 r17990. 2007-05-30 Chris Wilson <chris@chris-wilson.co.uk> * io-jpeg.c (gdk_pixbuf__jpeg_image_stop_load): Supply the current GError for fatal_error_handler(). (#441443)
Hi Chris. This commit broke the display of multi-part jpeg posts in the pan newsreader. Only the first part of a multi-part jpeg is actually displayed, the remaining parts (I assume) are simply ignored. I don't know the pan code very well (yet) but it uses a pixbuf for displaying the attachments, naturally. Any idea where in the processing of the multipart jpeg pan might need to be fixed? i.e. creating the pixbuf, combining the parts, redrawing the pixbuf, etc. Even a broad hint would help me get started. Many thanks.
I'm guessing that pan now receives an error after decoding the first part and gives up (whereas before the error disappeared into the void). I'd start by looking at how it's handling the error and checking the GError->message. That should hopefully gives some clues as to where the problem lies.
Yup, pan's event log contains a GError message complaining about too few scan lines. Just what you would expect from a multipart jpeg.
Pan has this problem even with single-part images. It appears to happen whenever the image data gets over a certain size. While attempting to isolate where exactly in the image it was failing, I wrote some code to load the image into the pixbuf loader in 1024 byte chunks rather than in one shot. Rather than isolate the location of the problem, this makes it go away entirely! Indeed, if I write the entire buffer being sent to gdk_pixbuf_loader_write to a file, I get a perfectly intact JPEG. See comment #4 in bug 477860 (and attached patch) for more details. Needless to say, unless there are caveats about the size of data you should be able to write to a pixbuf loader, I think this is clearly a bug on that side, not in Pan. Let me know if I should open a new bug for this. Unfortunately, I just use Pan, I don't write GTK+ or Gnome code, so I'm not really the best one to follow up on this.
(In reply to comment #7) See bug 494667.