Launchpad has imported 25 comments from the remote bug at https://bugzilla.novell.com/show_bug.cgi?id=322163.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2007-09-15T20:10:42+00:00 Twiest wrote: ---- Reported by awadd...@fnfr.com 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 lu...@ximian.com 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 awadd...@fnfr.com 2006-09-21 13:06:37 MST ---- Will do (the gdb bit). We're using 1.1.13.8. ---- Additional Comments From awadd...@fnfr.com 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 ?? () #1 0xbff1ab40 in ?? () #2 0x081be970 in __JCR_LIST__ () #3 0xbff1ab18 in ?? () #4 0x007b60d8 in recvfrom () from /lib/libpthread.so.0 #5 0x080f72de in _wapi_recvfrom (fd=9, buf=0x8458560, len=1024, recv_flags=0, from=0x0, fromlen=0x0) at sockets.c:498 #6 0x080f7234 in _wapi_recv (fd=4294966784, buf=0xfffffe00, len=4294966784, recv_flags=-512) at sockets.c:478 ---Type <return> to continue, or q <return> to quit--- #7 0x080baa47 in ves_icall_System_Net_Sockets_Socket_Receive_internal ( sock=4294966784, buffer=0xbff1ab18, offset=136046960, count=1024, flags=-512, error=0xbff1ac00) at socket-io.c:1212 #8 0xb721eedb in ?? () #9 0x00000009 in ?? () #10 0x08458550 in ?? () #11 0x00000000 in ?? () (gdb) ---- Additional Comments From psi...@fnfr.com 2006-10-06 14:00:20 MST ---- Created an attachment (id=170526) c# code ---- Additional Comments From psi...@fnfr.com 2006-10-06 14:00:46 MST ---- Created an attachment (id=170527) Makefile ---- Additional Comments From psi...@fnfr.com 2006-10-06 14:01:31 MST ---- Seems to happen if we leave threads running before exiting main and threads are actively running and using AutoResetEvents, ManualResetEvents, etc... ---- Additional Comments From d...@ximian.com 2006-11-13 18:07:41 MST ---- I've been unable to reproduce this with current svn. I've tested on several machines, to see if variations in cpu speed showed a race condition. On which version of mono exactly are you seeing the bug? If it happens again, running "mono --wapi=seminfo" should show the PID of the mono process that is holding the semaphore locked. Getting a backtrace of that process should show what's causing it. (If your mono installation is too old to have that option, it's also older than several fixed bugs of this variety.) ---- Additional Comments From mig...@ximian.com 2007-01-01 16:55:39 MST ---- Setting bug to NEEDINFO. Imported an attachment (id=170526) Imported an attachment (id=170527) Unknown bug field "cf_op_sys_details" encountered while moving bug <cf_op_sys_details>Red Hat Enterprise Linux WS release 4</cf_op_sys_details> Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/6 ------------------------------------------------------------------------ On 2008-05-02T22:00:10+00:00 Jeremy Allison wrote: 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. Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/20 ------------------------------------------------------------------------ On 2008-05-06T11:52:30+00:00 Dick-novell wrote: To start with, versions of relevant software (mono --version, f-spot etc) Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/21 ------------------------------------------------------------------------ On 2008-05-07T00:22:10+00:00 Jeremy Allison wrote: $ 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. Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/22 ------------------------------------------------------------------------ On 2008-05-07T10:12:36+00:00 Dick-novell wrote: Does this laptop have a dual-core cpu? Another possible thing to try would be valgrind's lock checker Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/23 ------------------------------------------------------------------------ On 2008-05-07T10:13:50+00:00 Dick-novell wrote: Or even just a gdb backtrace Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/24 ------------------------------------------------------------------------ On 2008-05-07T12:40:03+00:00 Vargaz wrote: The runtime shutdown code was rewritten in mono 1.9, precisely to fix bugs like this, so you might want to try that version. Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/25 ------------------------------------------------------------------------ On 2008-05-07T14:26:37+00:00 Fxjrlists wrote: 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. Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/26 ------------------------------------------------------------------------ On 2008-05-07T14:58:47+00:00 Vargaz wrote: Try updating to 1.9. Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/27 ------------------------------------------------------------------------ On 2008-05-19T21:42:52+00:00 Jeremy Allison wrote: 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. Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/28 ------------------------------------------------------------------------ On 2008-05-19T21:53:30+00:00 Jeremy Allison wrote: *** Bug 391823 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/29 ------------------------------------------------------------------------ On 2008-05-19T22:08:13+00:00 Vargaz wrote: 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 Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/30 ------------------------------------------------------------------------ On 2008-05-19T22:15:08+00:00 Jeremy Allison wrote: 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. Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/31 ------------------------------------------------------------------------ On 2008-05-19T22:50:34+00:00 Vargaz wrote: 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... Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/32 ------------------------------------------------------------------------ On 2008-05-19T22:58:36+00:00 Miguel de Icaza wrote: 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. Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/33 ------------------------------------------------------------------------ On 2008-05-20T00:24:26+00:00 Jeremy Allison wrote: 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> Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/34 ------------------------------------------------------------------------ On 2008-05-20T19:49:57+00:00 Miguel de Icaza wrote: 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? Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/35 ------------------------------------------------------------------------ On 2008-05-20T21:22:15+00:00 Sdelcroix wrote: what gtk-sharp version are you using ? Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/36 ------------------------------------------------------------------------ On 2008-05-20T21:40:38+00:00 Miguel de Icaza wrote: 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 Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/37 ------------------------------------------------------------------------ On 2008-05-21T00:21:19+00:00 Jeremy Allison wrote: (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. Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/38 ------------------------------------------------------------------------ On 2008-09-06T20:57:57+00:00 Jim-the-matthews wrote: 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 ?? () #11 0xb312219b in ?? () #12 0xb44cfea8 in ?? () #13 0xb6cfa2a4 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #14 0xb6cecc3b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #15 0xb6d016f2 in ?? () from /usr/lib/libgobject-2.0.so.0 #16 0xb6d0267e in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #17 0xb6d02ae6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #18 0xb67ddb21 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #19 0xb68ed121 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #20 0xb68fa8f6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #21 0xb6cef24f in g_object_run_dispose () from /usr/lib/libgobject-2.0.so.0 #22 0xb67dd80e in gtk_object_destroy () from /usr/lib/libgtk-x11-2.0.so.0 #23 0xa8eeeef9 in ?? () #24 0xa8eeeebb in ?? () #25 0xa8eeee7b in ?? () #26 0xa8d0e02d in ?? () #27 0xa8d0db7b in ?? () #28 0xb312219b in ?? () #29 0xb44cfea8 in ?? () #30 0xb6cfa2a4 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #31 0xb6cecc3b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #32 0xb6d016f2 in ?? () from /usr/lib/libgobject-2.0.so.0 #33 0xb6d0267e in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #34 0xb6d02ae6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #35 0xb68e99d7 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #36 0xb67c9790 in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0 #37 0xb67cb58d in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #38 0xb67c216b in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #39 0xb67bbdf6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #40 0xb6ceb389 in ?? () from /usr/lib/libgobject-2.0.so.0 #41 0xb6cecc3b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #42 0xb6d00e7f in ?? () from /usr/lib/libgobject-2.0.so.0 #43 0xb6d0250c in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #44 0xb6d02ae6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #45 0xb68e4b6e in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #46 0xb67b4a5c in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #47 0xb67b5d3f in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #48 0xb6624a9a in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #49 0xb7fec2d9 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #50 0xb7fef85b in ?? () from /usr/lib/libglib-2.0.so.0 #51 0xb7fefd2a in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #52 0xb67b6279 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #53 0xa8e18c6e in ?? () #54 0xa8e18c38 in ?? () #55 0xa8e18c20 in ?? () #56 0xb790975a in ?? () #57 0xb79081c4 in ?? () #58 0x080efba7 in mono_runtime_exec_main () #59 0x080f018d in mono_runtime_run_main () #60 0x0805af33 in mono_main () #61 0x0805a422 in ?? () #62 0xb7e195f5 in __libc_start_main () from /lib/libc.so.6 #63 0x0805a361 in ?? () #0 0xffffe430 in __kernel_vsyscall () Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/40 ------------------------------------------------------------------------ On 2008-10-09T06:20:42+00:00 Vargaz wrote: 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 Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/42 ------------------------------------------------------------------------ On 2009-01-14T17:20:33+00:00 Casualprogrammer-gmail wrote: Really impressive thread, anybody still interested ? Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/43 ------------------------------------------------------------------------ On 2009-01-14T18:29:51+00:00 Vargaz wrote: 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. Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/44 ------------------------------------------------------------------------ On 2010-11-27T19:01:06+00:00 Rkumpera wrote: No response. Shutdown received many more fixes since 2.0 Reply at: https://bugs.launchpad.net/f-spot/+bug/123979/comments/45 ** Changed in: f-spot Status: In Progress => Unknown ** Changed in: f-spot Importance: Unknown => Medium -- 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 member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
