do you have a dbus session running ? i.e., are you running f-spot from inside a gnome-session ?

does running 'dbus-launch f-spot' helps ?

Yes, I'm running F-spot under a gnome session.
'dbus-launch f-spot' seems launch the same error.

dbus-launch f-spot:

$ dbus-launch f-spot
Stacktrace:

  at (wrapper managed-to-native) NDesk.GLib.IO.g_io_add_watch (NDesk.GLib.IOChannel,NDesk.GLib.IOCondition,NDesk.GLib.IOFunc,intptr) <0xffffffff>
  at (wrapper managed-to-native) NDesk.GLib.IO.g_io_add_watch (NDesk.GLib.IOChannel,NDesk.GLib.IOCondition,NDesk.GLib.IOFunc,intptr) <0x000a4>
  at NDesk.GLib.IO.AddWatch (NDesk.GLib.IOChannel,NDesk.GLib.IOCondition,NDesk.GLib.IOFunc) <0x00064>
  at NDesk.DBus.BusG.Init (NDesk.DBus.Connection,NDesk.GLib.IOFunc) <0x00080>
  at NDesk.DBus.BusG.Init (NDesk.DBus.Connection) <0x000cc>
  at NDesk.DBus.BusG.Init () <0x00044>
  at FSpot.Driver.Main (string[]) <0x00394>
  at (wrapper runtime-invoke) System.Object.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0x00080>

Native stacktrace:

	f-spot [0x1016572c]
	f-spot [0x1013f0e4]
	[0x100350]
	[(nil)]
	/usr/lib/libglib-2.0.so.0(g_io_add_watch_full+0x5c) [0xff1011c]
	[0x3123b9dc]
	[0x3123b858]
	[0x3123b53c]
	[0x3123b3c8]
	[0x311b1b40]
	[0x30b8a7a8]
	[0x30b880dc]
	f-spot [0x1013ef0c]
	f-spot(mono_runtime_invoke+0x1c) [0x100563d8]
	f-spot(mono_runtime_exec_main+0x14c) [0x1005b958]
	f-spot(mono_runtime_run_main+0x2a4) [0x1005bc4c]
	f-spot(mono_jit_exec+0xe0) [0x100134ec]
	f-spot [0x10013628]
	f-spot(mono_main+0x1714) [0x10014fd0]
	f-spot [0x100120d4]
	/lib/libc.so.6 [0xfc5afa0]
	/lib/libc.so.6 [0xfc5b1f0]

Debug info from gdb:

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 805445168 (LWP 3888)]
[New Thread 818603184 (LWP 3894)]
[New Thread 805491888 (LWP 3893)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0x0fd160e8 in select () from /lib/libc.so.6
  3 Thread 805491888 (LWP 3893)  0x0fe92ce0 in ?? () from /lib/libpthread.so.0
  2 Thread 818603184 (LWP 3894)  0x0fe8e2b4 in pthread_cond_wait@@GLIBC_2.3.2
    () from /lib/libpthread.so.0
  1 Thread 805445168 (LWP 3888)  0x0fd160e8 in select () from /lib/libc.so.6

+ Trace 149069

=================================================================
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.
=================================================================

Abortado

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

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

Could you try building f-spot from SVN HEAD?

I think I ran into this too, updating it helps (or maybe just rebuilding should suffice). No idea what might cause it though.

So... does recompiling fix it ? it looks like a gutsy problem...

My problem from #458964 (assuming it is the same; I am on PPC so you never know) got fixed somewhere down the line, as the same release of f-spot works for me now. I think it was this:

ndesk-dbus-glib (0.3-2) unstable; urgency=low

  * debian/patches/01_native-signatures.dpatch:
    + Fix the signatures of the native GLib functions to prevent crashes on
      architectures where managed structs are not passed as pointer to native
      functions. This fixes the segfaults on PPC for example. (Closes: #431168)
      Thanks to Mirco Bauer for investigation.

 -- Sebastian Dröge <slomo@debian.org>  Sun, 22 Jul 2007 19:27:32 +0200

Thanks for looking into it,

Andy.

Created attachment 93676 [details] [review]
debian's ndesk-dbus patch

apply with patch -p2 < ndesk-dbus.patch

as i am aware it affects only ppc.

debian's patch for ndesk-dbus patch helps.

there is also another patch in debian, which forces f-spot to use
external ndesk-dbus-glib. imho, that's much better solution.

> there is also another patch in debian, which forces f-spot to use
> external ndesk-dbus-glib. imho, that's much better solution.
> 

indeed, but only if it's available. It's not (yet) distributed on all distros.

well, ndesk dbus is being released for some period of time, currenly.

if f-spot (and tomboy) require external ndesk dbus, then there is
less hassle to fix software (debian's ndesk dbus patch has to be
applied to f-spot and tomboy, now). therefore a little push from
f-spot to package ndesk dbus in distros is perceived by me as
great thing. :)

but this is probably chicken and egg problem.

as of r3316, ndesk-dbus is only compiled and bundled if it's not already installed.

Since Stephane's comment indicates that this bug should have a workaround from r3316, could someone confirm it the latest SVN fixes this problem or not?

I can confirm that I can run f-spot from cvs without problems, if that's what you are asking.

Yes, since you can run it, I am closing the bug as fixed then
Thanks :)