GNOME Bugzilla – Bug 633188
f-spot crashes when printing
Last modified: 2018-07-01 09:03:55 UTC
this report has been filed here: https://bugs.edge.launchpad.net/ubuntu/+source/f-spot/+bug/657505 "I have a fully updated Maverick 64-bit (somewhere between RC and final) (F-spot 0.8.0-1) . The printer I am using here is the HP PhotoSmart Premium C309g-m with the "hpcups" driver. I try to print a single photo (3:2 aspect ratio, from a DSLR) on 10x15cm/6x4in photo paper. I proceed exactly the same (too ugly and not user-friendly) way as I do with shotwell, but in shotwell it works perfectly: 1. Start f-spot from the command line 2. Click on the thumbnail of the photo to be printed 3. Choose File -> Page Setup 4. In the dialog choose the desired printer in the first drop-down, then choose the desired paper size in the second drop-down, and after that the orientation of the photo. 5. Choose File -> Print 6. Choose the desired printer (again), go through the tabs and check whether everything is OK. Especially make sure that the photo tray is chosen on the "Page Setup" tab, that print quality lis "Best" and that color output is set. After that click "Print". 7. In this moment f-spot crashes, no job gets sent to CUPS. The following appears in the terminal window: till@till:~/printing/foomatic/foomatic/foomatic-db$ f-spot & [1] 21344 till@till:~/printing/foomatic/foomatic/foomatic-db$ ** No session dbus found. Starting one ** [Info 20:38:42.368] Initializing Mono.Addins (f-spot:21344): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference. Exception in Gtk# callback delegate Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception. System.NullReferenceException: Object reference not set to an instance of an object at FSpot.PrintOperation.OnDrawPage (Gtk.PrintContext context, Int32 page_nr) [0x00000] in <filename unknown>:0 at Gtk.PrintOperation.drawpage_cb (IntPtr operation, IntPtr context, Int32 page_nr) [0x00000] in <filename unknown>:0 at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal) at Gtk.PrintOperation.drawpage_cb(IntPtr operation, IntPtr context, Int32 page_nr) at Gtk.PrintOperation.gtk_print_operation_run(IntPtr , Int32 , IntPtr , IntPtr ByRef ) at Gtk.PrintOperation.Run(PrintOperationAction action, Gtk.Window parent) at FSpot.MainWindow.HandlePrintCommand(System.Object sender, System.EventArgs e) at System.Reflection.MonoMethod.InternalInvoke(System.Object , System.Object[] , System.Exception ByRef ) at System.Reflection.MonoMethod.Invoke(System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) at System.Reflection.MethodBase.Invoke(System.Object obj, System.Object[] parameters) at System.Delegate.DynamicInvokeImpl(System.Object[] args) at System.MulticastDelegate.DynamicInvokeImpl(System.Object[] args) at System.Delegate.DynamicInvoke(System.Object[] args) at GLib.Signal.ClosureInvokedCB(System.Object o, GLib.ClosureInvokedArgs args) at GLib.SignalClosure.Invoke(GLib.ClosureInvokedArgs args) at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) at Gtk.Application.gtk_main() at Gtk.Application.Run() at FSpot.Driver.Startup() at Hyena.Gui.CleanRoomStartup.Startup(Hyena.Gui.StartupInvocationHandler startup) at FSpot.Driver.Main(System.String[] args) [1]+ Exit 1 f-spot till@till:~/printing/foomatic/foomatic/foomatic-db$"
Created attachment 175289 [details] debug output from f-spot crash
I can confirm this bug. I have attached debug output from f-spot. $ uname -a Linux harley 2.6.35-23-generic-pae #40-Ubuntu SMP Wed Nov 17 22:32:51 UTC 2010 i686 GNU/Linux
Same stack trace on Fedora 14 while performing the same steps but printing to a Canon iP4600. $ uname -a Linux ralph.fraser-green.com 2.6.35.6-45.fc14.x86_64 #1 SMP Mon Oct 18 23:57:44 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux $ rpm -q f-spot f-spot-0.8.0-3.fc14.x86_64
I get this too. Ubuntu 10.10 attempting to print to a Canon ip2600 on a Windows7 share.
Created attachment 181019 [details] output using f-spot --debug
Can confirm this bug in Fedora 14 x86_64 with all updates as of today. [duncan@rutherford ~]$ uname -a Linux rutherford.innes.net 2.6.35.11-83.fc14.x86_64 #1 SMP Mon Feb 7 07:06:44 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux [duncan@rutherford ~]$ rpm -q f-spot f-spot-0.8.2-1.fc14.x86_64 Any movement on this issue? Quite a biggie not being able to print from f-spot.
I have confirmed it locally and narrowed it down to a call to Pixbuf.ScaleSimple in PixbufUtils.ScaleToMaxSize which results in a null and causes the exception several lines later. The documentation says that ScaleSimple will return null if not enough memory is available for the operation but that seems unlikely in my case (6 GB total RAM with only 1.4 used when running the test).
(In reply to comment #7) > I have confirmed it locally and narrowed it down to a call to > Pixbuf.ScaleSimple in PixbufUtils.ScaleToMaxSize which results in a null and > causes the exception several lines later. The documentation says that > ScaleSimple will return null if not enough memory is available for the > operation but that seems unlikely in my case (6 GB total RAM with only 1.4 used > when running the test). Based on your findings I have investigated the problem a little bit more: I tried to create a print preview: - for a picture with a size of 2592 x 1944 pixels - Paper size : US letter, Portrait - ScaleToMaxSize was called with a width and height of 108850 x 138648 That's clearly way too large: assuming 32bit/pixel: 108850 * 138648 * 4 / 1024 / 1024 / 1024 = 56GByte ;-) I have narrowed it down a little bit more to src/Clients/MainApp/FSpot/PrintOperation.cs: OnDrawPage: - the size is calculated here: ----------------------------------------------- double w = context.Width / ppx; double h = context.Height / ppy; // compute picture size using 4800DPI double mx=(w / 25.4) * 4800, my=(h / 25.4) * 4800; ----------------------------------------------- Some debug output on my system: context.Width: 575.999982698696 context.Height: 733.679982698696 ppx: 1, ppy: 1 w: 575.999982698696 h: 733.679982698696, mx: 108850.39043125 my: 138648.18570684 If I decrease the dpi value of 4800 to something like 400 it works fine. However, I'm not sure about the intention of the formula above and so I don't know what's the appropriate fix for this.
I found the same thing but the only thing I tried was to halve the DPI and that didn't make a difference. However, I'm glad that changing that did get it to work as it seemed suspicious. We'll have to see what an appropriate fix would be, user select DPI?
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.