are the two of you still able to reproduve this?  I can't on my dual opteron 64

I am at least, but it doesn't seem to happen so often as before. Earlier it happened often just during normal usage. Now I have scrolled and scrolled and scrolled to reproduce it. I think it's way more seldom now. Which is good :)

I get this a lot! I am using an SMP kernel on a CPU wit hyperthreading. It typically comes when I browse images (scrolling up/down I think). Should I keep an eye on something specific?

Anders, can you do anything in specific to cause it?  What version of f-spot are you using?

I'm still using 0.1.10, so maybe this isn't the most updated information.

I have just reproduced it by scrolling up and down, double clicking on a picture and made a fast double click to get back to browsing before the picture was completly updated (and I didn't get back).

That's usually what I do as well when this happens, but I have no way to reliably reproduce it. Sometimes it happens just when scrolling, other times it happens when doing what Anders just said. But it seems very intermittent.

Still the same for me. Ubuntu Dapper with P4 and Hyperthreading

Is there anything I can provide to fix this bug? It's more than annoying not being able to use SMP only because of F-Spot...

I found a comment on the Mono Gtk FAQ:
http://www.mono-project.com/FAQ:_Gtk#My_application_crashes_with_threads

As per the link in comment #8, it looks to be a call to Gtk+ that are done from outside the thread that invoked Application.Run

Have you been able to come up with a step-by-step of how to reproduce it?

There is not particular step-by-step of how to reproduce it because it does not happen everytime at the same time. "Start up F-Spot and scroll around a bit and/or view some images" would be the most accurate description, however this is not very detailed...

It is also my experience that there is no step by step reproducing method to get the crash. When I use f-spot it happens within 5 minutes if I do something real that requires scrolling. It seems like fast operations with the scroll wheel increases the chance of an async, but that could simply be because it can happen a lot more places.

The problem seems to have disappeard for me. Some days ago i shiftet profile in gentoo, and thought that it might be a good idea to recompile all packages where the flags have been changed.

I have a list of recompiled packages. I think the following is the problem:
dev-lang/mono-1.1.13.4  was not compiled with the nptl flag before but is now. nptl is Native POSIX threads library.

I get this on FreeBSD since the first time I tried F-Spot. What should I do to debug?


FreeBSD 6.1-STABLE
Mono JIT compiler version 1.1.13.6
	TLS:           normal
	GC:            Included Boehm (with typed GC)
	SIGSEGV      : altstack
Gnome f-spot 0.1.11

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

As per, http://bugzilla.gnome.org/show_bug.cgi?id=333071#c12 this does not seem to be the problem with Ubuntu (which already is compiled with --with-tls=__thread (which seems to have superseeded --with-nptl=yes).

Still seeing this bug.

The problem has reappeared for me. Either it was something else or I just had a lucky day.

I've just commited a patch I hope might resolve this to cvs. Please test and provide feedback.

Still there... It _might_ have gotten better, because it was really hard to reproduce tonight (but sometimes it is very hard to reproduce), but it's not gone, unfortunately :(

Totally unrelated with this bug, but I got a crash with this message once as well:

The program 'f-spot' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 608224 error_code 1 request_code 233 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

with 0.3.0 I'm completely unable to reproduce this testing on a dual opteron.  Can you still reproduce it?  Have you gotten any closer to figuring out how to produce it?  

FWIW, i used to have this also, but it has been quite a while already since I last had this.

I just got it again, with latest cvs from tonight. But it's became much more seldom lately. I have used it a couple of days for tagging a lot of new images, and it was just today I got the infamous message...

I was thinking, this is a rather slow SMP system, could that be the reason none of you others are seeing it? Because your systems are way faster?

I have also seen this. It has occurred twice during startup. F-spot draws one or two pictures in the browser then hangs. On the terminal I see the message about unexpected async reply.

uname -a 
Linux apfitch2 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:19 EST 2006 i686 i686 i386 GNU/Linux

F-spot from cvs last night (3 jan 1:20 GMT)

Alan

Hi there!

I would like to continue this issue, because I started work on some dual core (i686) machines under linux 2.6. (basicaly debian stable) and run into severe problems with threads. I use python with thread support and trying hard to work correctly with thread_enter and thread_leave commands in my idle callbacks...

It does not appear on single core machines and could be reproduced with gtk 2.8 and gtk 2.10.

Are there any news to this bug?

Still experience this as of svn r3207.

0.3.5 under debian does this often on dualcore smp cpu.

it seems to happen when i scroll while f-spot access the db in the back, at least it usually happens on console between 
open uri = ...
entries. sometimes happens when i tag something and change back to browse mode too fast. 
almost always seem to be related to screen refresh while accessing the db, but i only guess.

Keeping the other bug, as it has more recent activity.

*** This bug has been marked as a duplicate of 478243 ***

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

Thank you, Stephane! I really disagreed with Lorenzo's decision, but he have more bugzilla points than me :P

I can confirm Peter's observation that it seems to always be related to screen refresh while accessing the db. Or something. It has nagged me for almost four years now.

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

On Debian Sid, with f-spot from SVN, I can still reproduce. This is the best stack trace I could get:

+ Trace 202948

It clearly shows that thread5 sent a request to X, but unfortunately not where it did that.

Got this now, by installing xcb debug symbols and breaking in xcb_send_request in all threads but 1:

(gdb) bt

+ Trace 202949

I can probably get more by rebuilding gtk-sharp with debug symbols, but maybe that's enough to figure out the problem?

Johan, am not sure your issue is the same as the xlib async reply

(In reply to comment #32)
> Johan, am not sure your issue is the same as the xlib async reply
> 

Hmm it sure looks very much like the same. Debian is now using xlib / xcb, but the assertion failing in xcb is precisely about sequence number mismatch in x messages.

I'm getting this now, with 0.4.3.1.  It's kinda sudden, and may be related to the gnome 2.23.9x that I have installed. It reliably happens to me when browsing pictures in the "big image with little thumnails on top" mode.  Just hitting next for 5-10 times causes the hang.

Update: It's hugely less likely to happen if I turn off the filmstrip.  I had to browse several hundred pictures to get it to happen.

I can confirm this is still happening with f-spot 0.5.0.2. Problem is however that it is quite hard to reproduce. I've got a feeling that it is highly more likely to happen when you are browsing around without waiting for each picture to be loaded completely. That is continue browsing when the current image is still blurred.

If anybody has got any idea as to how I can try to debug this problem, or produce somehow useful debug output I'd be glad to help.

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.