f-spot.exe crashed with SIGSEGV in g_datalist_clear()

[Brett Alton]

Binary package hint: f-spot

Sorry to be so vague, but this simply occurred after importing photos for the first time, looking at the imported tags and then exiting.

ProblemType: Crash
Architecture: i386
Date: Wed Jul 4 08:35:32 2007
Disassembly: 0xb6c91490:
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/lib/f-spot/f-spot.exe
InterpreterPath: /usr/bin/mono
NonfreeKernelModules: nvidia
Package: f-spot 0.3.5-1
PackageArchitecture: i386
ProcCmdline: f-spot /usr/lib/f-spot/f-spot.exe
ProcCwd: /home/kaitlin
ProcEnviron:
 SHELL=/bin/bash
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_CA.UTF-8
Signal: 11
SourcePackage: f-spot
Stacktrace:
 #0 0xb6c91490 in ?? ()
 #1 0xb7f1f408 in g_datalist_clear () from /usr/lib/libglib-2.0.so.0
 #2 0xb62e2d58 in ?? () from /usr/lib/libgobject-2.0.so.0
 #3 0x0861f050 in ?? ()
 #4 0x00000000 in ?? ()
StacktraceTop:
 ?? ()
 g_datalist_clear () from /usr/lib/libglib-2.0.so.0
 ?? () from /usr/lib/libgobject-2.0.so.0
 ?? ()
 ?? ()
Title: f-spot.exe crashed with SIGSEGV in g_datalist_clear()
Uname: Linux bateman 2.6.22-7-generic #1 SMP Mon Jun 25 17:33:14 GMT 2007 i686 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin netdev plugdev powerdev scanner video
SegvAnalysis:
 Segfault happened at: 0xb6c91490:
 PC (0xb6c91490) not located in a known VMA region (needed executable region)!
SegvReason: executing unknown VMA

[Apport retracing service (apport)]

StacktraceTop:?? ()
IA__g_datalist_clear (datalist=0x861f050) at /build/buildd/glib2.0-2.13.6/glib/gdataset.c:120
g_object_finalize (object=0x861f048) at /build/buildd/glib2.0-2.13.6/gobject/gobject.c:540
gnome_program_finalize (object=0x861f048) at gnome-program.c:724
IA__g_object_unref (_object=0x861f048) at /build/buildd/glib2.0-2.13.6/gobject/gobject.c:1793

[Jeroen Maris (jealma)]

I can confirm this bug. Just opened F-spot to look around a bit. It came up with a photo import wizard, which I closed cause I had no photo's available at that moment. Then I closed the program and it crashed. Apport sent a bug report and after firefox opened it had the exact same bug description as above.

[Boris Dušek (dusek)]

I confirm this bug on Gutsy Tribe 3 + all updates as of Jul 28. I did the same thing as Jeroen - since I am testing Gutsy in VMware, I had no photos, so I simply clicked "Cancel" on the import dialog that's displayed when you run F-Spot for the first time. Then the main window appeared, and this crash ocurred.

[Mark A. Hershberger (hexmode)]

importing some pics, exporting to folder, and then quit. crashed during quit.

[Twiest (twiest)]

---- Reported by <email address hidden> 2006-09-20 22:16:57 MST ----

Please fill in this template when reporting a bug, unless you know what you
are doing.
Description of Problem: we've seen several cases where our C# program has
finished the last line of main() but we never get back to the Linux prompt
as mono appears to be hung. When it's in this state, we can't run any
other mono programs until the "hanging" one is killed. Is it possible that
the mono runtime has a lock somewhere which prevents other instances from
running it and when one runtime instance is holding the lock forever??

Steps to reproduce the problem:
we haven't yet been able to consistently reproduce this, but we've seen it
several time. killing the one that is hung frees everthing up.

We'll keep trying, but thought it was worth entering the bug. Perhaps
there is something we can do to troubleshoot it when it gets in this state.

Actual Results:

Expected Results:

How often does this happen? every once in a while

Additional Information:

---- Additional Comments From <email address hidden> 2006-09-21 11:03:43 MST ----

This looks like an issue with the io-layer.
When it happens again, please attach gdb to the hanging mono process
and get a backtrace of all the threads (type 'thread apply all bt' at
the gdb prompt). Also, what preecise version of mono are you using
(mono --version)?

---- Additional Comments From <email address hidden> 2006-09-21 13:06:37 MST ----

Will do (the gdb bit). We're using 1.1.13.8.

---- Additional Comments From <email address hidden> 2006-09-26 13:21:41 MST ----

I encountered the hang again. There are 2 mono processes. The first
yields:

(gdb) thread apply all bt

(gdb) bt

#0 0x0038a410 in ?? ()

#1 0xbfb79858 in ?? ()

#2 0x00000000 in ?? ()

The 2nd process seems to have more info:

(gdb) thread apply all bt

Thread 5 (Thread -1213420640 (LWP 14556)):

#0 0x0038a410 in ?? ()

#1 0xb7aca388 in ?? ()

#2 0x00000001 in ?? ()

#3 0x00ad8011 in ?? ()

#4 0x0047236d in semop () from /lib/libc.so.6

#5 0x080fe496 in _wapi_shm_sem_lock (sem=-4) at shared.c:483

#6 0x081042de in _wapi_handle_update_refs ()

    at ../../mono/io-layer/handles-private.h:319

#7 0x080fe5f5 in collection_thread (unused=0x0) at collection.c:37

#8 0x007b040b in start_thread () from /lib/libpthread.so.0

#9 0x00470b7e in clone () from /lib/libc.so.6

Thread 4 (Thread -1218552928 (LWP 14557)):

#0 0x0038a410 in ?? ()

#1 0xb75e5270 in ?? ()

#2 0x0000866b in ?? ()

#3 0x00000000 in ?? ()

Thread 3 (Thread -1222575200 (LWP 14559)):

#0 0x0038a410 in ?? ()

#1 0xb720ef94 in ?? ()

---Type <return> to continue, or q <return> to quit---

#2 0x00008b93 in ?? ()

#3 0x00000000 in ?? ()

Thread 2 (Thread -1225593952 (LWP 14560)):

#0 0x0038a410 in ?? ()

#1 0xb6f2e458 in ?? ()

#2 0xb6f2e338 in ?? ()

#3 0xb6f2e3b8 in ?? ()

#4 0x00469e11 in ___newselect_nocancel () from /lib/libc.so.6

#5 0xb6fca3cc in Tcl_InitNotifier () from /usr/lib/libtcl8.4.so

#6 0x007b040b in start_thread () from /lib/libpthread.so.0

#7 0x00470b7e in clone () from /lib/libc.so.6

Thread 1 (Thread -1208580416 (LWP 14555)):

#0 0x0038a410 in ?? ()
...

[dissection (bfkelsey)]

 confirm this bug on 8.04 beta. f-spot would not close, I had to force it.

[Alexandr Rudenko (hinode-mikado)]

 confirm this bug on 8.04 beta.

[Alexey Shumitsky (alexey-shumitsky)]

Confirm this bug on 8.04 beta.

[spectrum3 (spectrum3)]

Confirm this bug on 8.04 beta.

[Alan Hanley (a.hanley)]

Confirm this bug on 8.04 Beta as well ..

[Dan (djgavenda2)]

Alan,

How do you want me to confirm this? A log file? Which one and where do I send it?

Dan

Alan Hanley <email address hidden> wrote: Confirm this bug on 8.04 Beta as well ..

--
f-spot.exe crashed with SIGSEGV in g_datalist_clear()
https://bugs.launchpad.net/bugs/123979
You received this bug notification because you are a direct subscriber
of the bug.

Status in Source Package "f-spot" in Ubuntu: Triaged

Bug description:
Binary package hint: f-spot

Sorry to be so vague, but this simply occurred after importing photos for the first time, looking at the imported tags and then exiting.

ProblemType: Crash
Architecture: i386
Date: Wed Jul 4 08:35:32 2007
Disassembly: 0xb6c91490:
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/lib/f-spot/f-spot.exe
InterpreterPath: /usr/bin/mono
NonfreeKernelModules: nvidia
Package: f-spot 0.3.5-1
PackageArchitecture: i386
ProcCmdline: f-spot /usr/lib/f-spot/f-spot.exe
ProcCwd: /home/kaitlin
ProcEnviron:
 SHELL=/bin/bash
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_CA.UTF-8
Signal: 11
SourcePackage: f-spot
Stacktrace:
 #0 0xb6c91490 in ?? ()
 #1 0xb7f1f408 in g_datalist_clear () from /usr/lib/libglib-2.0.so.0
 #2 0xb62e2d58 in ?? () from /usr/lib/libgobject-2.0.so.0
 #3 0x0861f050 in ?? ()
 #4 0x00000000 in ?? ()
StacktraceTop:
 ?? ()
 g_datalist_clear () from /usr/lib/libglib-2.0.so.0
 ?? () from /usr/lib/libgobject-2.0.so.0
 ?? ()
 ?? ()
Title: f-spot.exe crashed with SIGSEGV in g_datalist_clear()
Uname: Linux bateman 2.6.22-7-generic #1 SMP Mon Jun 25 17:33:14 GMT 2007 i686 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin netdev plugdev powerdev scanner video

 __________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[Martin G Miller (mgmiller)]

confirm 8.04 beta daily build 11 April, 2008.
Detected camera ok and imported photos. Crashes on exiting fspot.

This is an improvement over 7 April and earlier which would cause a hard freeze on selecting the camera. No kb or mouse. Only a forced reboot from reset button would restart system.

[Laszlo Kupcsik (koopac)]

confirm 8.04 beta 12 April, 2008
Did not even import anything, just looked around, and added some comments to one of the pictures. Exported Galleries to folder.

Then crashed during quit.

[Jeffrey Ratcliffe (jeffreyratcliffe)]

With 8.04 beta, f-spot seems ALWAYS to segfault on quitting.

[Jeffrey Ratcliffe (jeffreyratcliffe)]

Simply open, look at some photos, quit resulted this time in:

(f-spot:13412): GLib-GObject-CRITICAL **: g_object_ref: assertion `object->ref_count > 0' failed
Segmentation fault (core dumped)

[Laszlo Kupcsik (koopac)]

8.04 beta it crashes often, but not always for me. It still falls far from the expected behaviour :)

[Dan Andreșan (danyer)]

On my system, 8.04 release candidate now, I agree with Jeffrey Ratcliffe: f-spot ALWAYS segfault on quitting.
I don't even have pictures in f-spot. Just started, exited, crashed.

Leather, Rinse, Repeat: start, exit, crash :(

[Pedro Villavicencio (pedro)]

Still an issue with latest package on Hardy Heron, the crash at exit is fixed with bug 199496. thanks.

[Jeremy Allison (jra-samba)]

I can reproduce this 100% on my ubuntu 8.04 laptop trying to run f-spot.exe. Application hangs on selecting File -> Quit. Please let me know what details you need to track down and fix this (looks like a mono pthread bug to me).

Jeremy.

[Dick-novell (dick-novell)]

To start with, versions of relevant software (mono --version, f-spot etc)

[Jeremy Allison (jra-samba)]

$ mono --version
Mono JIT compiler version 1.2.6 (tarball)
Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com
 TLS: __thread
 GC: Included Boehm (with typed GC)
 SIGSEGV: altstack
 Notifications: epoll
 Architecture: x86
 Disabled: none

F-Spot 0.4.2

You may not be able to reproduce this. I can't on anything other than this laptop. Some help debugging pthread locking issues on mono would help.

Thanks.

Jeremy.

[Dick-novell (dick-novell)]

Does this laptop have a dual-core cpu?

Another possible thing to try would be valgrind's lock checker

[Dick-novell (dick-novell)]

Or even just a gdb backtrace

[Vargaz (vargaz)]

The runtime shutdown code was rewritten in mono 1.9, precisely to fix bugs like
this, so you might want to try that version.

[Fxjrlists (fxjrlists)]

I can reproduce 100% of time when executing nant.exe

Here is the backtrace:

Thread 3 (Thread 0xb769db90 (LWP 21365)):
#0 0xb7fda410 in __kernel_vsyscall ()
#1 0x4cce6aa5 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0x081088ff in ?? ()
#3 0xb7b971dc in ?? ()
#4 0xb7b971c4 in ?? ()
#5 0x4cceb14f in pthread_getaffinity_np@@GLIBC_2.3.4 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#6 0x0810b3cd in ?? ()
#7 0x00000000 in ?? ()

Thread 2 (Thread 0xb7c25b90 (LWP 21364)):
#0 0xb7fda410 in __kernel_vsyscall ()
#1 0x4ccea196 in nanosleep () from /lib/tls/i686/cmov/libpthread.so.0
#2 0x08105c91 in ?? ()
#3 0xb7c25344 in ?? ()
#4 0x00000000 in ?? ()

Thread 1 (Thread 0xb7fc6940 (LWP 21361)):
#0 0xb7fda410 in __kernel_vsyscall ()
#1 0x4cce7ae7 in pthread_kill () from /lib/tls/i686/cmov/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#2 0x08131f92 in ?? ()
#3 0xb769db90 in ?? ()
#4 0x0000001e in ?? ()
#5 0x00000001 in ?? ()
#6 0x081255d0 in ?? ()
#7 0x00000000 in ?? ()
#0 0xb7fda410 in __kernel_vsyscall ()

My machine is a pentium4m with HT but I disabled ht. I will reenable it to see if this still applies.

I'm using Ubuntu Hardy mono version. 1.2.6
mono --version
Mono JIT compiler version 1.2.6 (tarball)
Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com
 TLS: __thread
 GC: Included Boehm (with typed GC)
 SIGSEGV: altstack
 Notifications: epoll
 Architecture: x86
 Disabled: none

Interestingly, if I just call gmcs which also creates a mono process, it doesn't hang.

Thanks in advance.

[Vargaz (vargaz)]

Try updating to 1.9.

[Jeremy Allison (jra-samba)]

Ok, I've upgraded to 1.9.1 from the mono site using the supplied debian package and the problem still persists (f-spot hangs on exit).

Yes, the laptop is dual core.

Some help debugging pthread locking issues on mono would help.

Jeremy.

[Jeremy Allison (jra-samba)]

*** Bug 391823 has been marked as a duplicate of this bug. ***

[Vargaz (vargaz)]

As f-spot is quite a complex program, with lots of unmanaged code, gtk# etc. I'm not 100% sure this is a mono runtime problem. Anyways, there were some additional
fixes in the shutdown code after 1.9, so the situation will hopefully
improve when mono 2.0 is out:

http://lists.ximian.com/pipermail/mono-patches/2008-May/117840.html
http://lists.ximian.com/pipermail/mono-patches/2008-May/117882.html

[Jeremy Allison (jra-samba)]

Ok, I'm not having this. You recommended 1.9.x, I've tried that and it's *still* broken. Just how hard can shutting down a process be ! There's no guarantee that these patches will fix anything more than the previous lot.

Just give me some constructive suggestions as to how to debug this please and I'll try and sort it out myself. This is a blocker bug for me as f-spot hosts all my family photos.

Jeremy.

[Vargaz (vargaz)]

Shutting down a managed runtime is not easy, see
http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx
for a discussion of how the MS.NET runtime does it. Basically, we could just
call libc exit () and be done with it, but people expect finalizers to be called
etc. Some people even expect us to clean up all memory used by the runtime.
Since cleaning up runtime memory structures while some threads are running which use them is not wise, we need to (at least) suspend all managed threads.
suspending threads is again not easy, since unix has no SuspendThread call like
win32 does, if a thread is suspended while holding some lock, the whole stuff
could deadlock. So this is not a simple problem at all, and I'm not suprised that
there are bugs. Also, as I said, f-spot is not a simple program, so it might
itself hang even when the runtime shutdown code works fine.

For a quick-and-dirty solution, you could try patching f-spot so instead of
calling Environment.Exit (), it would pinvoke the libc exit () function. That
would most likely work, except when some library like gtk installs an atexit ()
handler which does some strange thing and crashes/hangs...

[Miguel de Icaza (miguel)]

Am not sure that the F-Spot issue is the same as the other issues.

Jeremy, if you do not mind, could you send the QUIT signal to the hung process and dump the output? That should give us a stack trace of where the program is stuck.

[Jeremy Allison (jra-samba)]

Here's the backtrace from the QUIT signal sent to the mono instance running f-spot.exe.

$ mono /usr/lib/f-spot/f-spot.exe
Starting new FSpot server
Reloading
item changed

(f-spot:13837): 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.
Full thread dump:

"" tid=0x0xb7d27940 this=0x0x34e10:
  at (wrapper managed-to-native) System.Environment.Exit (int) <0x00004>
  at (wrapper managed-to-native) System.Environment.Exit (int) <0xffffffff>
  at FSpot.Core.HandleDestroyed (object,System.EventArgs) <0x00049>
  at Gtk.Object.OnDestroyed () <0x000a0>
  at Gtk.Object.NativeDestroy (object,System.EventArgs) <0x0002e>
  at GLib.Signal.voidObjectCallback (intptr,intptr) <0x000da>
  at (wrapper native-to-managed) GLib.Signal.voidObjectCallback (intptr,intptr) <0xffffffff>
  at (wrapper managed-to-native) Gtk.Object.gtk_object_destroy (intptr) <0x00004>
  at (wrapper managed-to-native) Gtk.Object.gtk_object_destroy (intptr) <0xffffffff>
  at Gtk.Object.Destroy () <0x0002a>
  at Gtk.Widget.Destroy () <0x0000a>
  at MainWindow.Close () <0x00460>
  at MainWindow.HandleDeleteEvent (object,Gtk.DeleteEventArgs) <0x0000f>
  at Gtk.Widget.DeleteEventSignalCallback (intptr,intptr,intptr) <0x00146>
  at (wrapper native-to-managed) Gtk.Widget.DeleteEventSignalCallback (intptr,intptr,intptr) <0xffffffff>
  at (wrapper managed-to-native) Gtk.Application.gtk_main () <0x00004>
  at (wrapper managed-to-native) Gtk.Application.gtk_main () <0xffffffff>
  at Gtk.Application.Run () <0x00007>
  at Gnome.Program.Run () <0x00007>
  at FSpot.Driver.Main (string[]) <0x00cf1>
  at (wrapper runtime-invoke) FSpot.Driver.runtime_invoke_int_string[] (object,intptr,intptr,intptr) <0xffffffff>

[Miguel de Icaza (miguel)]

Bummer. It looks like its Mono's fault.

Jeremy, would you mind attaching to the Mono process with gdb, when it hangs and then issue this command:

(gdb) t a a bt

And post the output?

[Sdelcroix (sdelcroix)]

what gtk-sharp version are you using ?

[Miguel de Icaza (miguel)]

Stephane believes that this might be a bug in Gtk# object destruction code, so we are wondering how to get a fix that can be tested on Ubuntu.

http://groups.google.com/group/mono-svn-patches/browse_frm/thread/e62749a36aa425ed/532c4dac2df85fa7?lnk=gst&q=r102731#532c4dac2df85fa7

The patch was committed on r102731

[Jeremy Allison (jra-samba)]

(gdb) t a a bt

Thread 6 (Thread 0xb77bfb90 (LWP 11138)):
#0 0xb7f49410 in __kernel_vsyscall ()
#1 0xb7e5c196 in nanosleep () from /lib/tls/i686/cmov/libpthread.so.0
#2 0x08119f81 in ?? ()
#3 0xb77bf344 in ?? ()
#4 0x00000000 in ?? ()

Thread 5 (Thread 0xb723cb90 (LWP 11139)):
#0 0xb7f49410 in __kernel_vsyscall ()
#1 0xb7e58aa5 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0x0811eeaf in ?? ()
#3 0xb77361dc in ?? ()
#4 0xb77361c4 in ?? ()
#5 0x088d3a80 in ?? ()
#6 0x0007ca08 in ?? ()
#7 0x00000001 in ?? ()
#8 0xb6c42780 in gconf_value_free () from /usr/lib/libgconf-2.so.4
#9 0x0812197d in ?? ()
#10 0x00000000 in ?? ()

Thread 4 (Thread 0xb3ef4b90 (LWP 11155)):
---Type <return> to continue, or q <return> to quit---
#0 0xb7f49410 in __kernel_vsyscall ()
#1 0xb7e58dd2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0x0811ee6a in ?? ()
#3 0xb7736680 in ?? ()
#4 0xb7736668 in ?? ()
#5 0xb3ef4074 in ?? ()
#6 0xb6a00000 in ?? ()
#7 0xb6aaf9b8 in ?? ()
#8 0xb3ef4074 in ?? ()
#9 0xb7736680 in ?? ()
#10 0xb3dd7360 in ?? () from /usr/lib/libsqlite3.so.0
#11 0xb7e598c5 in pthread_getspecific ()
   from /lib/tls/i686/cmov/libpthread.so.0
#12 0x0812197d in ?? ()
#13 0x00000001 in ?? ()
#14 0x0811fac0 in ?? ()
#15 0x00000000 in ?? ()

Thread 3 (Thread 0xb29b8b90 (LWP 11158)):
#0 0xb7f49410 in __kernel_vsyscall ()
#1 0xb7e58dd2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#2 0x0811ee6a in ?? ()
#3 0xb773689c in ?? ()
#4 0xb7736884 in ?? ()
#5 0xb29b807c in ?? ()
#6 0xb29b8074 in ?? ()
#7 0x00000000 in ?? ()

Thread 2 (Thread 0xb28b3b90 (LWP 11159)):
#0 0xb7f49410 in __kernel_vsyscall ()
#1 0xb7e58dd2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0x0811ee6a in ?? ()
#3 0xb77369e0 in ?? ()
#4 0xb77369c8 in ?? ()
#5 0xb28b3074 in ?? ()
#6 0x00000001 in ?? ()
#7 0xb6ab77c8 in ?? ()
#8 0xb28b3074 in ?? ()
#9 0xb77369e0 in ?? ()
#10 0x08234240 in ?? ()
#11 0xb6ab5c18 in ?? ()
#12 0x483369b9 in ?? ()
#13 0x00c65d40 in ?? ()
---Type <return> to continue, or q <return> to quit---
#14 0x0821df08 in ?? ()
#15 0x00000001 in ?? ()
#16 0x00000000 in ?? ()

Thread 1 (Thread 0xb7c99940 (LWP 11137)):
#0 0xb7f49410 in __kernel_vsyscall ()
#1 0xb7e58dd2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2 0x0811ee6a in ?? ()
#3 0x08220f20 in ?? ()
#4 0x08220f00 in ?? ()
#5 0xbfb66c48 in ?? ()
#6 0x00002b81 in ?? ()
#7 0x00000000 in ?? ()
#0 0xb7f49410 in __kernel_vsyscall ()

(gdb)

gtk-sharp installed is : libgtk2.0-cil 2.12.0-2ubuntu3

Jeremy.

[Claudiu Vlad (claudiu-vlad)]

Seems to be mono's fault (?!) according to these guys: https://bugzilla.novell.com/show_bug.cgi?id=322163
Please fix ASAP, as fspot is crashing EVERY TIME here on Hardy Heron.

[Jim-the-matthews (jim-the-matthews)]

Same consistent problem here with OpenSuSE 11.0:
f-spot 0.4.3.1-17.1
gtk-sharp2 2.12.1-9.2

> uname -r
2.6.25.11-0.1-default

> mono --version
Mono JIT compiler version 1.9.1 (tarball)

(gdb) thread apply all bt

Thread 6 (Thread 0xb73a7b90 (LWP 19085)):
#0 0xffffe430 in __kernel_vsyscall ()
#1 0xb7f7a3e6 in nanosleep () from /lib/libpthread.so.0
#2 0x0811d588 in ?? ()
#3 0xb7f73175 in start_thread () from /lib/libpthread.so.0
#4 0xb7ed0dce in clone () from /lib/libc.so.6

Thread 5 (Thread 0xb7383b90 (LWP 19086)):
#0 0xffffe430 in __kernel_vsyscall ()
#1 0xb7f76c15 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2 0x08129cb7 in ?? ()
#3 0x0812c2ec in ?? ()
#4 0x0812c32c in ?? ()
#5 0x0812d4ea in ?? ()
#6 0x08188a7a in ?? ()
#7 0x080c8334 in ?? ()
#8 0x081238be in ?? ()
#9 0x0813eed5 in ?? ()
#10 0xb7f73175 in start_thread () from /lib/libpthread.so.0
#11 0xb7ed0dce in clone () from /lib/libc.so.6

Thread 4 (Thread 0xb45d9b90 (LWP 19087)):
#0 0xffffe430 in __kernel_vsyscall ()
#1 0xb7f76f42 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#2 0x08129c68 in ?? ()
#3 0x0812c2ec in ?? ()
#4 0x0812c32c in ?? ()
#5 0x0812d4ea in ?? ()
#6 0x080c53d3 in ?? ()
#7 0xb59b68c2 in ?? ()
#8 0xb59b66b3 in ?? ()
#9 0xb59b53e3 in ?? ()
#10 0xb790be79 in ?? ()
#11 0x080ebc35 in mono_runtime_delegate_invoke ()
#12 0x080c839f in ?? ()
#13 0x081238be in ?? ()
#14 0x0813eed5 in ?? ()
#15 0xb7f73175 in start_thread () from /lib/libpthread.so.0
#16 0xb7ed0dce in clone () from /lib/libc.so.6

Thread 3 (Thread 0xb30d7b90 (LWP 19091)):
#0 0xffffe430 in __kernel_vsyscall ()
#1 0xb7f76f42 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#2 0x08129c68 in ?? ()
#3 0x0812c2ec in ?? ()
#4 0x0812c32c in ?? ()
#5 0x0812d4ea in ?? ()
#6 0x0810aa21 in ?? ()
#7 0xb30dc4ba in ?? ()
#8 0xb30dc39e in ?? ()
#9 0xb30dc2c0 in ?? ()
#10 0xb790be79 in ?? ()
#11 0x080ebc35 in mono_runtime_delegate_invoke ()
#12 0x080c839f in ?? ()
#13 0x081238be in ?? ()
#14 0x0813eed5 in ?? ()
#15 0xb7f73175 in start_thread () from /lib/libpthread.so.0
#16 0xb7ed0dce in clone () from /lib/libc.so.6

Thread 2 (Thread 0xb2fd6b90 (LWP 19092)):
#0 0xffffe430 in __kernel_vsyscall ()
#1 0xb7f76f42 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#2 0x08129c68 in ?? ()
#3 0x0812c2ec in ?? ()
#4 0x0812c32c in ?? ()
#5 0x0812d4ea in ?? ()
#6 0x0810aa21 in ?? ()
#7 0xb30dc4ba in ?? ()
#8 0xb30dc39e in ?? ()
#9 0xb30dc64e in ?? ()
#10 0xb790be79 in ?? ()
#11 0x080ebc35 in mono_runtime_delegate_invoke ()
#12 0x080c839f in ?? ()
#13 0x081238be in ?? ()
#14 0x0813eed5 in ?? ()
#15 0xb7f73175 in start_thread () from /lib/libpthread.so.0
#16 0xb7ed0dce in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb7e028f0 (LWP 19084)):
#0 0xffffe430 in __kernel_vsyscall ()
#1 0xb7f76f42 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
#2 0x08129c68 in ?? ()
#3 0x08129d32 in ?? ()
#4 0x0812d935 in ?? ()
#5 0x080c8dfa in mono_thread_suspend_all_other_threads ()
#6 0x080fecd5 in ?? ()
#7 0xa8d0f86e in ?? ()
#8 0xa8d0f7a2 in ?? ()
#9 0xa8eeeff1 in ?? ()
#10 0xa8eeef47 in ?? ()
...

[Claudiu Vlad (claudiu-vlad)]

I may confirm now the bugs is still there in Intrepid Ibex, after upgrading from Hardy heron.

[Vargaz (vargaz)]

FYI, in _some_ cases, not all, this is caused by a bug in gnupg-agent:

https://bugs.edge.launchpad.net/ubuntu/+source/mono/+bug/224291

[Casualprogrammer-gmail (casualprogrammer-gmail)]

Really impressive thread, anybody still interested ?

[Vargaz (vargaz)]

We are interested in seeing whenever ubuntu users who can repro this
problem can repro it after upgrading to mono 2.0, if/when mono 2.0 packages
for ubuntu become available.

[Rkumpera (rkumpera)]

No response. Shutdown received many more fixes since 2.0