Re: Application suddenly stuck at startup

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:

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/
#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 
#4  0x00007ffff4ef48d4 in g_thread_pool_wait_for_new_pool () at 
#5  g_thread_pool_thread_proxy (data=<optimized out>) at 
#6  0x00007ffff4ef4115 in g_thread_proxy (data=0x19da4f0) at 
#7  0x00007ffff7bc7b50 in start_thread () from /lib/x86_64-linux-gnu/
#8  0x00007ffff6e47a7d in clone () from /lib/x86_64-linux-gnu/
#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 :'( )


On Thu, Feb 28, 2013 at 8:01 AM, Jonathan Ballet <jon multani info> wrote:


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
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,



python-hackers-list mailing list
python-hackers-list gnome org

Attachment: stacktrace-sonata-stuck-2.txt.gz
Description: Binary data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]