How to track down a bug w/ PyGTK3 which freezes the UI?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How to track down a bug w/ PyGTK3 which freezes the UI?

Gtk+ - General mailing list
Hi,

I'm using PyGTK3 [python3.7, Debian 9.7 @ x86_64, Gtk 3.22.11] for an
embedded UI [X11, Xfce4, kiosk mode].

I noticed that after a while, the UI "freezes": the UI items are not
repainted anymore, whatever Gtk calls are invoked.

I initially thought the main loop was stuck for some reason, but it is
definitely not: execution goes on, application threads and UI thread
keep logging traces. I've also added a timer (GLib.timeout_add) which
keeps being called at the defined pace.

I double-checked that all calls made from the application threads to Gtk
loop directly go through GLib.idle_add; all events received from Gtk are
pushed into an event queue that the application thread manages, to avoid
any long calls that could be made from the main context.

Any hint on how to debug this kind of issue would be appreciated, as I'm
out of ideas. GDB is available on the test platform, although I'm not
sure how to track this issue from there.

Additional details about this problem:

UI items include several text labels, a progress bar, and two basic
drawing areas, all contained in a page of a notebook. The app is running
in full screen mode [800x480].

I run the app with some kind of auto-test mode, to run the same sequence
again and again until it freezes, without any user input - nor any input
event.

When it freezes, the application does not crash, the CPUs show no
noticeable load when the UI freezes.

The UI freezes "randomly", from 5 to 100 cycles. Each cycle last ~ 4
seconds. A cycle makes less than a hundred calls to Gtk API.

The UI provides a modal dialog to quit the app, which can be kicked in
from the main menu bar. When the UI is frozen, e.g. many calls to change
the content of the text label, the progress bar fraction value, etc.
have not been serviced, the dialog nevertheless shows up. Sometimes, its
contents is painted successfully, sometimes only the dialog frame (inc.
buttons) is displayed along with its title text, while the dialog
content area is not (re)painted...

Using the GTK+ inspector, I can see that the text labels, the progress
bar fraction, etc. are actually updated whereas the UI does not refresh
their contents. However, the GdkFrameClockIdle counters *all* stop as
the same time the UI is not updated anymore.

What could cause this kind of trouble, where the UI is not refreshed
anymore, but main context seems to be up and running?

Thanks,
Manu.
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|

Re: How to track down a bug w/ PyGTK3 which freezes the UI?

Gtk+ - General mailing list


> What could cause this kind of trouble, where the UI is not refreshed
> anymore, but main context seems to be up and running?

GdkFrameClock no longer receive update requests when this issue is
triggered.

What could cause the GdkFrameClock[Idle] not to be called?

Thanks,
Manu.
_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list