Extremely Random Pango Crashes

Question

As the title says, I've been running over some weird crashes, apparently caused by Pango or related.

My program works correctly, does everything on time, no weird visual glitches or errors of any other kind, BUT this kind of errors lead, usually, to a crash. Sometimes it just throws an exception and continues, but approximately 10% of those exceptions end in a crash, without mentioning I have no idea of what could be causing it.

Here are some logs of different attempts:

The most common one:

(App:23224): Pango-CRITICAL **: pango_layout_set_width: assertion 'layout != NULL' failed

(App:23224): Pango-CRITICAL **: pango_layout_get_width: assertion 'layout != NULL' failed

(App:23224): Pango-CRITICAL **: pango_layout_get_extents: assertion 'layout != NULL' failed

(App:23224): Pango-CRITICAL **: pango_layout_is_wrapped: assertion 'layout != NULL' failed

(App:23224): Pango-CRITICAL **: pango_layout_is_ellipsized: assertion 'layout != NULL' failed
./Def:822: Warning: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
  Gtk.main()

(App:23224): Pango-CRITICAL **: pango_layout_get_extents: assertion 'layout != NULL' failed

The more-or-less common one...

(App:22385): Pango-CRITICAL **: pango_layout_is_wrapped: assertion 'layout != NULL' failed

(App:22385): Pango-CRITICAL **: pango_layout_is_ellipsized: assertion 'layout != NULL' failed
./Def:820: Warning: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
  Gtk.main()

(App:22385): Pango-CRITICAL **: pango_layout_get_extents: assertion 'layout != NULL' failed

And the weirdest of all:

Pango:ERROR:/build/buildd/pango1.0-1.36.3/./pango/pango-layout.c:3916:pango_layout_check_lines: assertion failed: (!layout->log_attrs)

The last one has been only seen 1 time, the rest of errors are kind of common.

Ironically, the last one appeared when my App was still alive for record time, and then this error ended it suddenly, without even the "common" errors...

Any ideas what could be happening?

As I've said before, my app works as it should until one of the above errors end it.

More Info:

My app is multi-threaded, but this error doesn't seem to be related to threads...otherwise something else should complain too!

We would have to see some code. You can use `G_DEBUG=fatal-warnings` to have gdb break whenever a warning comes up to help debug. I do have a feeling your attempt to use GTK+ with multiple threads is causing this, though. — andlabs, Dec 04 '16 at 16:09
I have to agree with andlabs, this smells strongly of multi-threading issues. — Jussi Kukkonen, Dec 04 '16 at 23:18
I thought the same, but I don't have any other idea to constantly monitor a progress and, at the same time, update a progressbar! Meanwhile, I'll see if gdb detects something else... — PythonNoob, Dec 04 '16 at 23:26
Share the value through the threads using basic C type. GTK (like most tolkits) is not thread-safe, so trying to update your widget outside the main thread may cause strange issues. — liberforce, Dec 05 '16 at 12:35
I don't fully understand your comment...If I share my value, which is actually possible, I can't keep my ProgressBar updated anyways, because I would need to setup a monitor with a loop that will constantly update my ProgressBar, causing Gtk.main() to freeze, and that would freeze my widget too, so a "0% to 100%" ProgressBar would be kind of useless... — PythonNoob, Dec 06 '16 at 04:28
Found solution. Would you like to upvote it so people will be able to see it easily? — PythonNoob, Dec 06 '16 at 05:58

score 2 · Accepted Answer · edited May 23 '17 at 12:08

Well, after a quite long research, I did found This, This and This.

All of 'em were useful. The first one it's a link to another SO's question about the same topic, the second one it's a link to official GNOME's website for devs, were I found info about a curious Gdk function: Gdk.threads_add_idle, and the third one it's a link to a bug report from the aforementioned Gdk function, because in Python it asks for 3 args, when in C asks just for 2, but there it clarifies why it asks for 3.

It wasn't too difficult to fix this after I discovered Gdk.threads_add_idle.

I just had to move all my calls to Gtk to functions and, in the second thread, change all those calls with Gdk.threads_add_idle(priority, function, data), where priority should be GLib.PRIORITY_DEFAULT_IDLE and function must be the function containing all calls to Gtk.

data it's an optional argument. It shall contain all additional data that you would like to pass to function

Extremely Random Pango Crashes

1 Answers1