Ubuntu
f-spot package

f-spot crashes when exporting pictures to directory

Bug #115256 reported by Jean Levasseur
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
F-Spot
Won't Fix
Medium
f-spot (Ubuntu)
Triaged
Medium
Ubuntu Desktop Bugs

Bug Description

Binary package hint: f-spot

When exporting large amount of bog-sized pictures do directory, f-spot crashes. Here's the terminal output I got using "f-spot --debug" option:

(f-spot:11519): 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.

(f-spot:11519): 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.

(f-spot:11519): 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.

(f-spot:11519): 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.

(f-spot:11519): 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.
open uri = file:///media/multimedia/Photos/2007/03/18/img_6797.jpg
Insufficient memory (case 4)

The several WARING lines don't seem to make any problem as there is plenty others like those ones but still.

The last line seems to be the error that causes the crash.

To reproduce, I was exporting 208 pictures of about 2 Mb each. I have tried 4 times, every times it crashes reaching about 191 to 193 pictures.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducable with the live environment of the Desktop CD of the development release - Gutsy Gibbon. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

Changed in f-spot:
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
David Erosa (erosa) wrote :

I can confirm this bug on Feisty PPC, tried to export about 1600 images and always dies when about 850 files are copied.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thanks, to be send upstream by someone getting the bug.

Changed in f-spot:
status: Incomplete → New
Revision history for this message
ward (ward-pong) wrote :

Confirmed here on Feisty i386 - export to directory (in 'copy only' mode, no resize) crashes f-spot *every time* after about 50 out of 190 images.

Revision history for this message
ward (ward-pong) wrote :

I believe this is upstream bug #471713:

  http://bugzilla.gnome.org/show_bug.cgi?id=471713

Pedro Villavicencio (pedro)
Changed in f-spot:
status: New → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in f-spot:
status: Unknown → New
Revision history for this message
Torsten Spindler (tspindler) wrote :

The problem does not happen for me on Hardy when starting f-spot with sloppy locks enabled for xcb:

$ LIBXCB_ALLOW_SLOPPY_LOCK=1 f-spot

Revision history for this message
Béné (bene-d) wrote :

Torsten's fix seems not to work on Gutsy. The stacktrace remains the same as reported on http://bugzilla.gnome.org/show_bug.cgi?id=471713

Pedro Villavicencio (pedro)
Changed in f-spot:
assignee: nobody → desktop-bugs
status: Confirmed → Triaged
Bug Watch Updater (bug-watch-updater)
Changed in f-spot:
status: New → Invalid
Bug Watch Updater (bug-watch-updater)
Changed in f-spot:
status: Unknown → Confirmed
Revision history for this message
Jeffrey Ratcliffe (jeffreyratcliffe) wrote :
Download full text (6.2 KiB)

With an up-to-date Hardy I get the same warnings, one per image:

(f-spot:8054): 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.

and then it segfaults with this trace:

Stacktrace:

Native stacktrace:

 f-spot [0x816b1fa]
 f-spot [0x807de81]
 [0xb7f83440]

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Aborted

Torsten's fix seems not to work on Hardy. I get the additional output:

0xb7f21410 in __kernel_vsyscall ()
  8 Thread 0xb7223b90 (LWP 8233) 0xb7f21410 in __kernel_vsyscall ()
  7 Thread 0xb71ffb90 (LWP 8234) 0xb7f21410 in __kernel_vsyscall ()
  6 Thread 0xb4d1bb90 (LWP 8235) 0xb7f21410 in __kernel_vsyscall ()
  5 Thread 0xb363bb90 (LWP 8238) 0xb7f21410 in __kernel_vsyscall ()
  4 Thread 0xb3536b90 (LWP 8239) 0xb7f21410 in __kernel_vsyscall ()
  3 Thread 0xb1d7cb90 (LWP 8240) 0xb7f21410 in __kernel_vsyscall ()
  2 Thread 0xb13efb90 (LWP 8244) 0xb7f21410 in __kernel_vsyscall ()
  1 Thread 0xb7c7d940 (LWP 8232) 0xb7f21410 in __kernel_vsyscall ()

Thread 8 (Thread 0xb7223b90 (LWP 8233)):
#0 0xb7f21410 in __kernel_vsyscall ()
#1 0xb7e40196 in nanosleep () from /lib/tls/i686/cmov/libpthread.so.0
#2 0x08105c91 in ?? ()
#3 0xb7e384fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#4 0xb7d95e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 7 (Thread 0xb71ffb90 (LWP 8234)):
#0 0xb7f21410 in __kernel_vsyscall ()
#1 0xb7e3caa5 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0x081088ff in ?? ()
#3 0x0810b3cd in ?? ()
#4 0x0810b43c in ?? ()
#5 0x0811ba1a in ?? ()
#6 0x080b1c0a in ?? ()
#7 0x080cef04 in ?? ()
#8 0x0811a7c2 in ?? ()
#9 0x081317a5 in ?? ()
#10 0xb7e384fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#11 0xb7d95e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 6 (Thread 0xb4d1bb90 (LWP 8235)):
#0 0xb7f21410 in __kernel_vsyscall ()
#1 0xb7e3cdd2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0x081088ba in ?? ()
#3 0x0810b3cd in ?? ()
#4 0x0810b43c in ?? ()
#5 0x0811ba1a in ?? ()
#6 0x080cca8e in ?? ()
#7 0xb5af36c2 in ?? ()
#8 0xb5af32bb in ?? ()
#9 0xb5af1eeb in ?? ()
#10 0xb5af1d6a in ?? ()
#11 0xb7788fc9 in ?? ()
#12 0x08095ea4 in mono_runtime_delegate_invoke ()
#13 0x080cef6e in ?? ()
#14 0x0811a7c2 in ?? ()
#15 0x081317a5 in ?? ()
#16 0xb7e384fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#17 0xb7d95e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 5 (Thread 0xb363bb90 (LWP 8238)):
#0 0xb7f21410 in __kernel_vsyscall ()
#1 0xb7e3cdd2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0x081088ba in ?? ()
#3 0x0810b3cd in ?? ()
#4 0x0810b43c in ?? ()
#5 0x0811ba1a in ?? ()
#6 0x080cbc7e in ?? ()
#7 0xb363d982 in ?? ()
#8 0xb363...

Read more...

Revision history for this message
Canale Grande (canalegrande) wrote :

Confirmed on Hardy Heron 8/04

Thread 1 (Thread 0xb7d12940 (LWP 31085)):
#0 0xb7fb9410 in __kernel_vsyscall ()
#1 0xb7e20c07 in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7f1f1c6 in ?? () from /usr/lib/libglib-2.0.so.0
#3 0xb7f1f577 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#4 0xb6702264 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#5 0xb327dc1e in ?? ()
#6 0xb327dbe8 in ?? ()
#7 0xb327dbd0 in ?? ()
#8 0xb781478a in ?? ()
#9 0xb78131c4 in ?? ()
#10 0x0809c68e in mono_runtime_exec_main ()
#11 0x0809c933 in mono_runtime_run_main ()
#12 0x0805acd9 in mono_main ()
#13 0x0805a122 in ?? ()
#14 0xb7d6a450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#15 0x0805a091 in ?? ()
#0 0xb7fb9410 in __kernel_vsyscall ()

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

Aborted

Revision history for this message
Jean Levasseur (levasseur.jean) wrote :

I'm not able to reproduce anymore on Intrepid. I have tried to export to folder and it worked flawlessly. Can anyone with Intrepid confirm?

Revision history for this message
jkyamog (jkyamog) wrote :

Still a problem for me on Intrepid.

Revision history for this message
Fabien Cortina (fabien.cortina) wrote :

I have the same problem (on Intrepid), but on importing the pictures from a camera (or a card reader).

Here is the stack trace:

(f-spot:9760): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. Y
ou must explicitly end the data stream to the loader before dropping the last reference.
Error GeneraError: LibGPhoto2.GPhotoException: Erreur indéfinie
  at LibGPhoto2.Error.CheckError (ErrorCode error) [0x00000]
  at LibGPhoto2.CameraFile.Save (System.String filename) [0x00000]
  at GPhotoCamera.SaveFile (Int32 index, System.String filename) [0x00000]
  at FSpot.CameraFileSelectionDialog.SaveFile (Int32 index) [0x00000]
  at FSpot.CameraFileSelectionDialog.Download () [0x00000]
Launched application : 9923

Launching with "LIBXCB_ALLOW_SLOPPY_LOCK=1" f-spot-import didn't help.

Revision history for this message
walter---- (walter-van) wrote :

Hi,

for me it works without a problem in Intrepid.

Walter

Revision history for this message
savantelite (savantelite) wrote :

It still happens in Karmic but not as much. The frustrating part is losing all my work, like highlighting photos and ready-ing them for facebook export.

Revision history for this message
Kemel Zaidan aka Legendario (kemelzaidan) wrote :

I am having this problem in karmic

Revision history for this message
Kemel Zaidan aka Legendario (kemelzaidan) wrote :

http://ubuntuforums.org/showthread.php?t=1307641

Revision history for this message
Kemel Zaidan aka Legendario (kemelzaidan) wrote :

This problem seems to be caused by some gnome themes. Changing solves it.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the new comment seems to be bug #411941

Bug Watch Updater (bug-watch-updater)
Changed in f-spot:
importance: Unknown → Medium
Revision history for this message
Copolycube (copolycube) wrote :

I can confirm this bug. I tried some default themes and this seems to happen whatever gnome-theme I use.

--- BEFORE the crash, f-spot says that :

[Info 18:41:39.164] Initializing Mono.Addins

(f-spot:32256): 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.

---AT the moment of the crash this yields a bunch of Mono exceptions :

Marshaling activate signal
Exception in Gtk# callback delegate
  Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
  at FSpot.Extensions.ExportMenuItemNode.OnActivated (System.Object o, System.EventArgs e) [0x00000] in <filename unknown>:0
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <filename unknown>:0
  at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x00000] in <filename unknown>:0
  at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) [0x00000] in <filename unknown>:0
  at System.Delegate.DynamicInvoke (System.Object[] args) [0x00000] in <filename unknown>:0
  at GLib.Signal.ClosureInvokedCB (System.Object o, GLib.ClosureInvokedArgs args) [0x00000] in <filename unknown>:0
  at GLib.SignalClosure.Invoke (GLib.ClosureInvokedArgs args) [0x00000] in <filename unknown>:0
  at GLib.SignalClosure.MarshalCallback (IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) [0x00000] in <filename unknown>:0
   at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal)
   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)

Revision history for this message
jan (jan-ubuntu-h-i-s) wrote :

duplicate of https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/427205 ?

Bug Watch Updater (bug-watch-updater)
Changed in f-spot:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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