Hi Simon, On Thu, Feb 28, 2013 at 07:18:47PM -0800, Simon Feltman wrote: > Hi Jonathan, > > I don't know if this is the problem but it looks like there are calls being > made directly to a Gtk model within a Python thread which I can't image is > ok (specifically in _library_artwork_update which is where the deadlock > seems to occur). You might try wrapping the code within that function or > any call to Gtk within it with calls to Gdk.threads_enter/exit: > http://developer.gnome.org/gdk/unstable/gdk-Threads.html
Thanks for having a look. To see if it was changing anything, I tried to remove all the threading code from the application so it doesn't create nor new threads nor locks explicitly, nor do the other libraries used. It still gets stuck at startup, the main thread #1 on the same instructions, while the other seemed to be waiting (as far as I understand). I attached the new stacktraces to this message. > Aside from that, I think using Gio instead of attempting to use Python > threads and IO mixed with Gtk might help considerably with what you are > trying to do. I'm looking over Gio and the other asynchronous functions to remove most or all of the threads in the application, but I can't change anything if the application just doesn't start anymore :) There's another thread at startup, which stops after a while (around 10 seconds after startup), with the following stacktrace: Thread 4 (Thread 0x7fffe504f700 (LWP 3288)): #0 0x00007ffff7bcc64b in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffff4f10525 in g_cond_wait_until (cond=0x1a79fe8, mutex=<optimized out>, end_time=<optimized out>) at /build/buildd-glib2.0_2.35.8-1-amd64-lGLf9n/glib2.0-2.35.8/./glib/gthread-posix.c:859 #2 0x00007ffff4ea6641 in g_async_queue_pop_intern_unlocked (queue=0x1a79fe0, wait=1, end_time=70700337288) at /build/buildd-glib2.0_2.35.8-1-amd64-lGLf9n/glib2.0-2.35.8/./glib/gasyncqueue.c:424 #3 0x00007ffff4ea6c5a in g_async_queue_timeout_pop (queue=0x1a79fe0, timeout=15000000) at /build/buildd-glib2.0_2.35.8-1-amd64-lGLf9n/glib2.0-2.35.8/./glib/gasyncqueue.c:545 #4 0x00007ffff4ef48d4 in g_thread_pool_wait_for_new_pool () at /build/buildd-glib2.0_2.35.8-1-amd64-lGLf9n/glib2.0-2.35.8/./glib/gthreadpool.c:169 #5 g_thread_pool_thread_proxy (data=<optimized out>) at /build/buildd-glib2.0_2.35.8-1-amd64-lGLf9n/glib2.0-2.35.8/./glib/gthreadpool.c:366 #6 0x00007ffff4ef4115 in g_thread_proxy (data=0x19da4f0) at /build/buildd-glib2.0_2.35.8-1-amd64-lGLf9n/glib2.0-2.35.8/./glib/gthread.c:798 #7 0x00007ffff7bc7b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x00007ffff6e47a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #9 0x0000000000000000 in ?? () I'm not sure what it does (my guess is it's just initializing the thread pool used by the GLib?), but #1 is already waiting at that time. I'm looking over to understand why gdk_threads_dispatch() could get stuck. I guess there's probably *something* in the application that causes it, but as I'm not super-familiar with how Gtk/Gdk/GLib work, is it at least a good place to wonder what's happening ? (is it expected to get this kind of stacktrace in a working application ?) I'm really confused, I can't think of anything I changed between the moment it worked, and the moment it got stuck :( (I swear :'( ) Jonathan > On Thu, Feb 28, 2013 at 8:01 AM, Jonathan Ballet <j...@multani.info> wrote: > > > Hi, > > > > I'm developing^Whacking on a Gtk application [1] which uses PyGObject > > since a few months now. It's a client for the Music Player Daemon (mpd). > > > > Suddenly yesterday, I couldn't run it anymore: when I start it, the > > application initialization at the very beginning is alright, Gtk.Appliction > > "activate" signal is triggered and answered as usual, and then, everything > > hangs. *Something* get stuck *somewhere* and I can't run the application > > anymore... > > I tried to put aside all the things that would come up to my mind, which > > were: I didn't updated any libraries on my system, I stashed my current > > changes, I switched back the application to master, "git clean -fdx"'d it, > > switched off the player daemon, even restarted my computer in case a socket > > or another daemon was off somewhere, and I quickly patched > > threading.Thread(), threading.Condition() and GLib.idle_add() so they are > > just stubs so remove potentially blocking things. > > > > I was just trying a new piece of code (which I reverted since then) and > > I'm pretty sure I restarted the application just a couple of hours before > > without any troubles. I used to do it several times a day for weeks, and > > now, I'm really confused. > > > > So I fired up gdb and had a look at the result (see the attached file), > > and I would say the application is stuck waiting for gdk_threads_dispatch() > > to return (which seems to be waiting to get a lock) in the main thread (#1) > > (There's another thread, waiting for a Condition to be released, but I'm > > pretty sure it's not the faulty code since 1. it's in another thread, and > > 2. it still hangs even if I remove this code). > > > > There are probably tons of places where the application abuses Gtk, > > threads and stuff, and we are trying to sort things out one at a time, but > > it used to work OK until now, when I don't have anything anymore. > > > > How can I get a clue on what's happening? I don't know where to look know, > > and I'm as stuck as my application :( > > > > Any tips appreciated, > > > > Jonathan > > > > [1]: https://github.com/multani/**sonata<https://github.com/multani/sonata> > > > > _______________________________________________ > > python-hackers-list mailing list > > python-hackers-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/python-hackers-list > > > >
stacktrace-sonata-stuck-2.txt.gz
Description: Binary data
_______________________________________________ python-hackers-list mailing list python-hackers-list@gnome.org https://mail.gnome.org/mailman/listinfo/python-hackers-list
