f-spot hangs on exit.

I assume you mean "File>Quit". On a stock ubuntu install (with no ~/.gnome2/f-spot directory) I am unable to reproduce the issue. Can you try renaming the fspot dir and see if you can reproduce the issue?

Yes I meant File -> Quit. I tried with a .gnome2/f-spot directory and also after removing the directory - same problem. This is with an upgrade from 7.10, not a fresh install. It's 100% reproducible for me. How do I get mono to give me debug information on the lock states inside it. I tried using f-spot --debug but got no extra output.
Jeremy.

Crap, just checked with <email address hidden> and he can't reproduce the problem either. Means I'll have to track this thing down myself. Ok - how do I debug mono apps ? Can you give me any clues on how to find a deadlock ?
Jeremy.

Here is a (long) gdb backtrace of attaching to the mono binary once f-spot is in this hung state. It's hanging on a pthread_cond_timedwait syscall. Hopefully this helps. Mono debugger output to follow.

Jeremy.
-----------------------------------------------------------------------------------------------

gdb /usr/bin/mono
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(no debugging symbols found)
(gdb) attach 4011
Attaching to program: /usr/bin/mono, process 4011
Reading symbols from /usr/lib/libgthread-2.0.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgthread-2.0.so.0
Reading symbols from /lib/tls/i686/cmov/librt.so.1...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/librt-2.7.so...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/librt.so.1
Reading symbols from /usr/lib/libglib-2.0.so.0...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libglib-2.0.so.0
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libdl-2.7.so...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libpthread-2.7.so...
(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 0xb7c50940 (LWP 4011)]
[New Thread 0xb2770b90 (LWP 4034)]
[New Thread 0xb2875b90 (LWP 4033)]
[New Thread 0xb3ea6b90 (LWP 4014)]
[New Thread 0xb71f8b90 (LWP 4013)]
[New Thread 0xb777bb90 (LWP 4012)]
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/libm.so.6...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libm-2.7.so...(no debugging symbols found)...done.

(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/tls/i686/cmov/libc.so.6...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libc-2.7.so...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/libselinux.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib/libselinux.so.1
Reading symbols from /lib/ld-linux.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.7.so...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libpcre.so.3...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libpcre.so.3
Reading symbols from /lib/tls/i686/cmov/libnss_compat.so.2...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libnss_compat-2.7.so...(no debugging symbols found)...done.
(no debugging symbo...

And here is f-spot being run under the mono debugger. Once it hung on exit I ^C'ed the debugger and got a backtrace. Hope this helps. Looks like the damn thing is in the final stages of exit cleaning up the pthreads it created for itself (which is consistent with the gdb trace above). Now, the question is *why*...
Jeremy.

----------------------------------------------------------------------------

mdb /usr/lib/f-spot/f-spot.exe
Mono Debugger
(mdb) run
Starting program: /usr/lib/f-spot/f-spot.exe
Cannot load symbol file `/usr/lib/f-spot/f-spot.exe.mdb': Could not find file "/usr/lib/f-spot/f-spot.exe.mdb".
Cannot load symbol file `/usr/lib/f-spot/f-spot.exe.mdb'
Cannot load symbol file `/usr/lib/mono/gac/glib-sharp/2.12.0.0__35e10195dab3c99f/glib-sharp.dll.mdb': Could not find file "/usr/lib/mono/gac/glib-sharp/2.12.0.0__35e10195dab3c99f/glib-sharp.dll.mdb".
Cannot load symbol file `/usr/lib/mono/gac/glib-sharp/2.12.0.0__35e10195dab3c99f/glib-sharp.dll.mdb'
Cannot load symbol file `/usr/lib/mono/gac/gnome-sharp/2.20.0.0__35e10195dab3c99f/gnome-sharp.dll.mdb': Could not find file "/usr/lib/mono/gac/gnome-sharp/2.20.0.0__35e10195dab3c99f/gnome-sharp.dll.mdb".
Cannot load symbol file `/usr/lib/mono/gac/gnome-sharp/2.20.0.0__35e10195dab3c99f/gnome-sharp.dll.mdb'
Cannot load symbol file `/usr/lib/mono/gac/Mono.Addins.Setup/0.3.0.0__0738eb9f132ed756/Mono.Addins.Setup.dll.mdb': Could not find file "/usr/lib/mono/gac/Mono.Addins.Setup/0.3.0.0__0738eb9f132ed756/Mono.Addins.Setup.dll.mdb".
Cannot load symbol file `/usr/lib/mono/gac/Mono.Addins.Setup/0.3.0.0__0738eb9f132ed756/Mono.Addins.Setup.dll.mdb'
Cannot load symbol file `/usr/lib/mono/gac/gtk-sharp/2.12.0.0__35e10195dab3c99f/gtk-sharp.dll.mdb': Could not find file "/usr/lib/mono/gac/gtk-sharp/2.12.0.0__35e10195dab3c99f/gtk-sharp.dll.mdb".
Cannot load symbol file `/usr/lib/mono/gac/gtk-sharp/2.12.0.0__35e10195dab3c99f/gtk-sharp.dll.mdb'
Cannot load symbol file `/usr/lib/mono/gac/atk-sharp/2.12.0.0__35e10195dab3c99f/atk-sharp.dll.mdb': Could not find file "/usr/lib/mono/gac/atk-sharp/2.12.0.0__35e10195dab3c99f/atk-sharp.dll.mdb".
Cannot load symbol file `/usr/lib/mono/gac/atk-sharp/2.12.0.0__35e10195dab3c99f/atk-sharp.dll.mdb'
Cannot load symbol file `/usr/lib/f-spot/FSpot.Core.dll.mdb': Could not find file "/usr/lib/f-spot/FSpot.Core.dll.mdb".
Cannot load symbol file `/usr/lib/f-spot/FSpot.Core.dll.mdb'
Cannot load symbol file `/usr/lib/f-spot/Cms.dll.mdb': Could not find file "/usr/lib/f-spot/Cms.dll.mdb".
Cannot load symbol file `/usr/lib/f-spot/Cms.dll.mdb'
Cannot load symbol file `/usr/lib/mono/gac/Mono.Addins/0.3.0.0__0738eb9f132ed756/Mono.Addins.dll.mdb': Could not find file "/usr/lib/mono/gac/Mono.Addins/0.3.0.0__0738eb9f132ed756/Mono.Addins.dll.mdb".
Cannot load symbol file `/usr/lib/mono/gac/Mono.Addins/0.3.0.0__0738eb9f132ed756/Mono.Addins.dll.mdb'
Cannot load symbol file `/usr/lib/mono/gac/gnome-vfs-sharp/2.20.0.0__35e10195dab3c99f/gnome-vfs-sharp.dll.mdb': Could not find file "/usr/lib/mono/gac/gnome-vfs-sharp/2.20.0.0__35e10195dab3c99f/gnome-vfs-sharp.dll.mdb".
Cannot load symbol file `/usr/lib/mono/gac/gnome-vfs-sharp/2.20.0.0__35e10195dab3c99f/gnome-vfs-sharp.dll.mdb'
Cannot load s...

Interestingly enough this doesn't now look f-spot related. If I try and quit the mdb session this also hangs in the same way. Looks to me that mono isn't terminating processes containing threads correctly on this system.
Jeremy.

I've got exactly the same problem after upgrade to Hardy.
Removing f-spot config directory doesn't solve the problem either.

I created another fresh user and there the problem doesn't exist so maybe it's some kind of custom settings in our environments.

closing the f-spot task since that doesn't seem to be due to it

I've got the same problem.
F-Spot crashes, when I try to exit.

· I think this just happens, when Compiz is running.

I don't think so.
I replaced compiz with metacity (metacity --replace && killall compiz-decorator) and it didn't solve the problem.

are you using AMD64?

No, regular i386.

Just upgraded to mono 1.9.1 from the .deb package at the mono site. Still hangs in f-spot exit, no change.
Jeremy.

The same behaviour here . F-spot can't close cleanly. I upgraded from gutsy.

Same for me with Ubuntu 8.04 upgraded from 7.10.
Forcing the exit is the only way to quit.

I tried to clear the .gnome2/f-spot directory: no change at all.

Bug confirmed.

Often when I run eog, it opens a window, then hangs when trying to actually show an image. I also get several "atk-bridge-WARNING **: failure: no device event controller found."

stracing the hung process shows it waiting for a futex(...) call.

I see from Jeremy's debugging above that he has atk (assistive technologies) enabled, or mono enables it by default.

Since I disabled atk, I no longer get the atk-bridge messages, and eog no longer lock up when I start it.
(Sometimes, gimp would lock up for me on startup too, so have to see if this fixes it).
If you have atk enabled (System -> Preferences -> Assistive Technologies), you can disable in on a per-terminal shell basis by unsetting the GTK_MODULES environment variable.

Perhaps this is the same cause of f-spot's problem.

Unable to reproduce here - can you all paste the exact versions installed of the mono-jit and f-spot packages, and any other relevant info (e.g. 'low-down' things you've tweaked on your install e.g. fiddling with /sys)

The problem is solved for me. I think it happened after some package upgrade, but unfortunately I don't know exactly.

warp, is that a vote for closing the bug then? I'd like to wait for one other person to say the problem's gone away before I close it.

Do *NOT* close this bug. This bug is active on all my 8.04 (fully updated) systems. It is a mono issue connected with pthread termination (I got a confirmation of this from Miguel) and will not be fixed in 8.04 until the mono version in 8.04 is updated.

Jeremy.

I still confirm the presence of the bug in my fully updated laptop with ubuntu 8.04.

8.04 is a stable release, so "until the mono version in 8.04 is updated" would be never - and not via backports either, due to no upstream changes to major frameworks. If you can track down exactly which SVN revision fixed the bug, and that fix still can be applied against Ye Olde 1.2.6, then it may be possible to push a newer package with that patch included via hardy-updates.

I don't want to suggest it as any kind of "official" fix, but I *DO* produce Mono backports for Hardy on my PPA - I'd be curious if someone still experiencing problems still finds they experience problems with Mono 1.9.1 from there. If not, then given the packages are sourced from the current Ubuntu+1, it certainly would suggest the problem is only in the standard Hardy packages (and not in later releases)

Well then you shipped a *completely broken* package as your default photo manager in a long term supported release then (and that isn't even mentioning the printing bug where trying to print via f-spot to any other size than the default just emits the default paper size - yes, this is also somewhere in launchpad). Let's face it, you did *NO* testing on your default photo management package for a long term release. You must fix your QA processes if you want to be taken seriously in the long term. I don't care about your no upstream changes to major frameworks policy - if you're shipping default broken components then your policy needs an update.

Jeremy.

If it were "completely broken", it wouldn't have shipped. Worse than "completely broken" is "occasionally broken" - where it works for the developers, but not for some subset of users with an unidentified common trait.

Without a 'known bad' use case to try and fix, how do we fix it?

I'm especially interested by the suggestion that the problem does not occur for new users on supposedly broken systems - can anyone else who still has a problem confirm that?

I still have the problem in my system
I created a new test user to answer the question from directhex: the new user does not have the problem!

I can confirm that f-spot does not hang for new users on my 'broken' system.

Okay, Daniele, can you try another one for me? As your "broken" user, fire up a console, run the following:

mkdir /tmp/foo
export MONO_SHARED_DIR=/tmp/foo
f-spot

See if it quits normally then.

This problem exists on latest intrepid alphas as well.

directhex:
No way.
I followed your istructions:

mkdir /tmp/foo
export MONO_SHARED_DIR=/tmp/foo
f-spot

Same as usual: the only way to quit is forcing the exit.
:-(

How about:

mv ~/.wapi ~/.wapi.old
f-spot

On Wed, 2008-09-24 at 08:50 +0000, Vikrant wrote:
> This problem exists on latest intrepid alphas as well.

Cannot confirm. It was broken with Hardy, but after I upgrading my
testing machine it quits normally.

>How about:
>
> mv ~/.wapi ~/.wapi.old
> f-spot
>

Nothing to do.
Same as usual: need forcing to quit.
Sorry...

(Should I re-create ~/.wapi dir? What's wapi?)

It should recreate itself. It's used for inter-thread communication stuff, by all mono apps.

Okay, can you try to quit f-spot, and whilst it's hung, run "mono --wapi=hps" in a console? Paste the output from that command.

> Okay, can you try to quit f-spot, and whilst it's hung, run "mono --wapi=hps" in a console? Paste the output from that
> command.

Here it is.

dani@#####:~$ mono --wapi=hps
collection: 0 sem: 0x4d03c12e
  1 ( 1) [Process] 6 Un ([ BeagleDaemon.exe] pid: 8648 exit: 0)
  2 ( 1) [ Thread] 8 Un (proc: 8648, tid: -1211492032, state: 0, exit: 0, join: 0)
  3 ( 1) [Process] 8 Un ([ Search.exe] pid: 8649 exit: 0)
  4 ( 1) [ Thread] 8 Un (proc: 8649, tid: -1211291328, state: 0, exit: 0, join: 0)
  5 ( 1) [ Thread] 8 Un (proc: 8649, tid: -1221227632, state: 0, exit: 0, join: 0)
  6 ( 1) [ Thread] 8 Un (proc: 8648, tid: -1221325936, state: 0, exit: 0, join: 0)
  7 ( 1) [ Thread] 8 Un (proc: 8648, tid: -1237320816, state: 0, exit: 0, join: 0)
  8 ( 1) [ Thread] 8 Un (proc: 8648, tid: -1263535216, state: 0, exit: 0, join: 0)
  9 ( 1) [ Thread] 8 Un (proc: 8648, tid: -1264587888, state: 0, exit: 0, join: 0)
  a ( 1) [ Thread] 8 Un (proc: 8648, tid: -1265640560, state: 0, exit: 0, join: 0)
  b ( 1) [Process] 5 Un ([ IndexHelper.exe] pid: 9257 exit: 0)
  c ( 1) [ Thread] 6 Un (proc: 9257, tid: -1211864768, state: 0, exit: 0, join: 0)
  d ( 1) [ Thread] 6 Un (proc: 9257, tid: -1221686384, state: 0, exit: 0, join: 0)
  e ( 1) [ Thread] 6 Un (proc: 9257, tid: -1238369392, state: 0, exit: 0, join: 0)
  f ( 1) [ Thread] 6 Un (proc: 9257, tid: -1239422064, state: 0, exit: 0, join: 0)
 10 ( 1) [ Thread] 6 Un (proc: 9257, tid: -1240474736, state: 0, exit: 0, join: 0)
 11 ( 1) [Process] 9 Un ([ f-spot.exe] pid: 9764 exit: 0)
 12 ( 1) [ Thread] 8 Un (proc: 8648, tid: -1267745904, state: 0, exit: 0, join: 0)
 13 ( 1) [ Thread] 9 Un (proc: 9764, tid: -1211807424, state: 0, exit: 0, join: 0)
 14 ( 1) [ Thread] 9 Un (proc: 9764, tid: -1222952048, state: 0, exit: 0, join: 0)
 15 ( 1) [ Thread] 9 Un (proc: 9764, tid: -1262699632, state: 0, exit: 0, join: 0)
 16 ( 1) [ Thread] 9 Un (proc: 9764, tid: -1285653616, state: 0, exit: 0, join: 0)
 18 ( 1) [ Thread] 9 Un (proc: 9764, tid: -1286722672, state: 0, exit: 0, join: 0)
 1c ( 1) [ Thread] 6 Sg (proc: 9257, tid: -1242580080, state: 1, exit: 0, join: 0)
Fileshare hwm: 18
dev: 0x803 ino: 4620733 open pid: 8648 share: 0x3 access: 0x40000000 refs: 1
dev: 0x803 ino: 4620924 open pid: 8648 share: 0x3 access: 0x40000000 refs: 1
dev: 0xe ino: 9104 open pid: 8648 share: 0x3 access: 0x80000000 refs: 2
dev: 0x803 ino: 4620720 open pid: 9257 share: 0x3 access: 0x40000000 refs: 1

I spy something unexpected.

Can you run "beagle-shutdown", check that BeagleDaemon.exe and IndexHelper.exe are not running, then try f-spot again?

Ok: I run "beagle-shutdown" and I confirm that BeagleDaemon.exe and IndexHelper.exe are not running now.

F-spot hangs as usual.

Here is the new output of "mono --wapi=hps" (while f-spot is hanging).

dani@######:~$ mono --wapi=hps
collection: 0 sem: 0x4d03c016
  1 ( 1) [Process] 8 Un ([ f-spot.exe] pid: 12641 exit: 0)
  2 ( 1) [ Thread] 8 Un (proc: 12641, tid: -1211635392, state: 0, exit: 0, join: 0)
  3 ( 1) [ Thread] 8 Un (proc: 12641, tid: -1222780016, state: 0, exit: 0, join: 0)
  4 ( 1) [ Thread] 8 Un (proc: 12641, tid: -1263576176, state: 0, exit: 0, join: 0)
  5 ( 1) [ Thread] 8 Un (proc: 12641, tid: -1285477488, state: 0, exit: 0, join: 0)
  6 ( 1) [ Thread] 8 Un (proc: 12641, tid: -1286546544, state: 0, exit: 0, join: 0)
Fileshare hwm: 2

Still unable to reproduce - I built a test Feisty machine in VirtualBox, fed F-Spot some photos, ran the upgrade cycle twice, and still couldn't produce a hang on exit.

What is special on your machines? What "wrong" file in your home directories is causing the issue?

Try this one:
for i in $(gconftool --all-dirs /apps/f-spot); do echo --$i:; gconftool -a $i; done

> Still unable to reproduce - I built a test Feisty machine in VirtualBox, fed F-Spot some photos, ran the upgrade cycle
> twice, and still couldn't produce a hang on exit.

> What is special on your machines? What "wrong" file in your home directories is causing the issue?

It is quite frustrating, in fact...

> Try this one:
> for i in $(gconftool --all-dirs /apps/f-spot); do echo --$i:; gconftool -a $i; done

OK.
Here's my output:

dani@#####:~$ for i in $(gconftool --all-dirs /apps/f-spot); do echo --$i:; gconftool -a $i; done
--/apps/f-spot/dbus:
 read_only = true
--/apps/f-spot/screensaver:
 tag_id = 1
--/apps/f-spot/ui:
 group_adaptor_sort_asc = true
 main_window_width = 1240
 viewer_width = 640
 show_filmstrip = true
 show_toolbar = true
 import_window_width = 640
 show_sidebar = true
 sidebar_size = 274
 expanded_tags = [5]
 zoom = 0.4739583432674408
 tag_icon_size = 48
 group_adaptor = 0
 show_ratings = false
 viewer_show_filenames = true
 viewer_maximized = false
 glass_position = 79
 import_window_height = 443
 main_window_x = 35
 main_window_y = 79
 main_window_height = 691
 viewer_show_toolbar = true
 show_tags = true
 import_window_pane_position = 400
 maximized = false
 show_dates = false
 show_timeline = true
 viewer_height = 480
--/apps/f-spot/viewer:
 transparency = NONE
 trans_color = #000000
 interpolation = true
--/apps/f-spot/export:
--/apps/f-spot/metadata:
 embed_in_image = true
--/apps/f-spot/import:
 storage_path = /home/dani/Personali/Foto

Thanks for your help!

I'm trying to patch f-spot for more debugging output

Meanwhile, can you tell me what happens if you run a copy of f-spot, then run "f-spot -shutdown" in a different terminal window?

Oh, and install the mono-jit-dbg package, it might be needed later

Please install the replacement f-spot package in http://retro.apebox.org/fspot/

It is versioned so that it will immediately be marked as obsolete by update-manager. Simply run update-manager's update to put back the Ubuntu package.

This package should be VERY verbose when quitting, telling you exactly what it's doing:

jms@osc-franzibald:/tmp$ f-spot
WARNING: The add-in 'FSpot.__DefaultExporters,1.6' is trying to extend '/FSpot/Menus/Exports', but there isn't any compatible add-in defining this extension point
Starting new FSpot server
Reloading
item changed
**F-spot uses non-standard shutdown methods, herein detailed
toplevels.Remove (sender);
if (toplevels.Count == 0) {
if (db != null)
db.EmitDown ();
System.Environment.Exit (0);
jms@osc-franzibald:/tmp$

Normally, (as detailed in the source code), GTK# applications are meant to call Gtk.Application.Quit() to clean up and exit - but f-spot instead has its own code to muck around with running threads then call the master killswitch.

I want to know whether your hanging f-spot gets as far as System.Environment.Exit, or if it gets caught on the thread killing run - part of that question comes from your wapi=hps output showing one more thread than me. Depending on the outcome, it'll be clearer where to investigate further.

Hi directhex,

> Meanwhile, can you tell me what happens if you run a copy of f-spot,
> then run "f-spot -shutdown" in a different terminal window?

It happens that f-spot hangs as usual (here I am using the ubuntu package for f-spot).
That is what the terminal says:

dani@holoab:~$ f-spot -shutdown
Shutting down existing F-Spot server...
Found active FSpot server: ICoreProxy

> Please install the replacement f-spot package in
> http://retro.apebox.org/fspot/

Unfortunately I am on a i386 system (Intel(R) Pentium(R) Dual CPU T2330 @ 1.60GHz), the package is for amd64. Can you provide a i386 version of the package?

Whoops, i386 doesn't even occur to me these days.

Uploaded.

I installed f-spot_0.4.3.1-0ubuntu1~bunniesarecute1_i386.deb.

Here is the output of the terminal. I lanched f-spot and I tried to quit with no success, it hangs as usual. Then I forced the exit.

dani@#####:~$ f-spot
Starting new FSpot server
Reloading
item changed
error checking orientation

(f-spot:27915): 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 uses non-standard shutdown methods, herein detailed
toplevels.Remove (sender);
if (toplevels.Count == 0) {
if (db != null)
db.EmitDown ();
System.Environment.Exit (0);
Killed

Okay, another one to try, from upstream. There are three "lib" packages for your arch now in the same web location. Install them. You may need to download all three at once & use "dpkg -i *.deb"

Then test f-spot again. You can return to the standard Ubuntu package if you like (I found what I wanted from the modded F-Spot, and the modded GTK# is versioned higher than the Hardy package)

I installed all the lib packages (after solving some issues with dependences).

Same as usual.

dani@#####:~$ f-spot
Starting new FSpot server
Reloading
item changed
error checking orientation

(f-spot:893): 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 uses non-standard shutdown methods, herein detailed
toplevels.Remove (sender);
if (toplevels.Count == 0) {
if (db != null)
db.EmitDown ();
System.Environment.Exit (0);
Killed

Do you have gnupg-agent installed?

Yes, gnupg-agent is installed.

(Why?)

Remove it.

Then try f-spot again.

Oh, important: log out then back in after removing gnupg-agent.

IT WORKS!!

Thank you directhex!
Removing the gnupg-agent package did the trick.

Now f-spot closes normally when I want (by the way, I'm using the standard ubuntu package of f-spot).

Thanks again.
Bye.

D.

Ladies & gents, we have a positive lead: gnupg-agent's broken SigBlk mask mangling on i386 - not F-Spot or Mono's fault at all.

*IF* (big if) someone else can confirm this fix applies. Any of the other subscribers other than Daniele care to give it a whirl?

Sorry, cannot confirm on this end.
My f-spot was broken under hardy but an upgrade to intrepid solved the
issue for me. gnupg-agent is currently not installed (I cannot say if it
was removed during the upgrade process). Installing (and starting) it
does not change the fact that f-spot opens and closes without any
hickups.

On Tue, 2008-10-07 at 17:45 +0000, directhex wrote:
> Ladies & gents, we have a positive lead: gnupg-agent's broken SigBlk
> mask mangling on i386 - not F-Spot or Mono's fault at all.
>
> *IF* (big if) someone else can confirm this fix applies. Any of the
> other subscribers other than Daniele care to give it a whirl?
>

I just tested by removing gnupg-agent, no difference. f-spot still hangs. As I've said before, this looks like a pthread problem in the mono exit code.
Jeremy.

Please download, compile and run http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=test-signal.c;att=1;bug=499569

And paste the output

Real-time signals work fine on this system, I use it for developing Samba (which uses RT-signals for file lease notification).

./a.out
SIGRTMIN: 34
sigismember(): 0
SIGRT_1 received
SIGRT_2 received
SIGQUIT received

FYI: I hate signal handlers with printf(). Not sig-safe :-).
Jeremy.

I CONFIRM, after removing gnupg-agent, f-spot doesn't hang on quit any more !! :-D

Xubuntu 8.04 Hardy
Linux xxxxx 2.6.24-21-generic #1 SMP Tue Oct 21 23:43:45 UTC 2008 i686 GNU/Linux

Karol.

Can you reproduce this error with a newer Ubuntu version?

No, sorry. I do not use it anymore.

Best regards,

Dennis

Am 2012-10-29 10:00, schrieb Thomas Hotz:
> Can you reproduce this error with a newer Ubuntu version?
>
> ** Changed in: mono (Ubuntu)
> Status: Confirmed => Incomplete
>
> --
> You received this bug notification because you are subscribed to the
> bug
> report.
> https://bugs.launchpad.net/bugs/224291
>
> Title:
> f-spot hangs on exit.
>
> Status in “f-spot” package in Ubuntu:
> Invalid
> Status in “mono” package in Ubuntu:
> Incomplete
>
> Bug description:
> Binary package hint: mono
>
> Description: Ubuntu 8.04
> Release: 8.04
> Package: f-spot: /usr/bin/f-spot
>
>
> To reproduce. Upgraded installation. Start f-spot (either from the
> command line or a menu). Wait for the initial window to appear. Click
> on File -> Exit. The application hangs. stracing it shows it stuck in
> a futex wait. Looks like a mono locking issue to me.
>
> 100% reproducible. This is a blocker bug for me to upgrade all my
> desktop machines (f-spot is my primary photo manager).
>
> strace output when in hung state (endlessly loops):
>
> gettimeofday({1209483989, 221562}, NULL) = 0
> clock_gettime(CLOCK_REALTIME, {1209483989, 221663850}) = 0
> futex(0x8207aa4, 0x80 /* FUTEX_??? */, 51) = -1 ETIMEDOUT
> (Connection timed out)
> futex(0x8207a80, 0x81 /* FUTEX_??? */, 1) = 0
> semop(131074, 0xbf835a66, 1) = 0
> time(NULL) = 1209483989
> time(NULL) = 1209483989
> time(NULL) = 1209483989
> time(NULL) = 1209483989
> time(NULL) = 1209483989
> time(NULL) = 1209483989
> semop(131074, 0xbf835a76, 1) = 0
> semop(131074, 0xbf835a66, 1) = 0
> time(NULL) = 1209483989
> time(NULL) = 1209483989
> time(NULL) = 1209483989
> time(NULL) = 1209483989
> time(NULL) = 1209483989
> time(NULL) = 1209483989
> semop(131074, 0xbf835a76, 1) = 0
> gettimeofday({1209483989, 322863}, NULL) = 0
> clock_gettime(CLOCK_REALTIME, {1209483989, 322973699}) = 0
> futex(0x8207aa4, 0x80 /* FUTEX_??? */, 53 <unfinished ...>
>
> Let me know what more you need to track this down. Note this is
> *NOT*
> the same as the previously reported "f-spot crashes on exit" segv
> bugs
> reported, this is a hang.
>
> Jeremy.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/224291/+subscriptions