Gtk-CRITICAL error messages to Leo-Editor's standard error

[SegundoBob]

For years on three or four different Linux releases by three or four distributors, I've been seeing several instances per day of the following error messages to Leo-Editor's standard error file.  There is no other indication that anything is wrong.  Leo-Editor seems to run just fine when these errors occur.

Are the Leo-Editor developers aware of these errors?  Is the consensus that these errors are someone else's problem?  GTK?  Python?

Initial Errors in one instance of Leo-Editor:

(python:2035): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2035): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

Errors a few minutes later iin another instance of Leo-Editor:

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(process:3278): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(process:3535): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(process:3765): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(process:3914): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(process:4077): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(process:4152): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2537): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(process:4170): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

[gatesphere]

This seems to be a quirk of how python deletes objects after it's done
with them. Here's what I found on StackOverflow:
http://stackoverflow.com/questions/12433491/is-this-pyqt-4-python-bug-or-wrongly-behaving-code

No clue how we could fix it, though...

-->Jake

[gatesphere]

More info: http://stackoverflow.com/questions/18416201/core-dump-with-pyqt4

The second answer seems to say that QObjects created without a parent
are owned by Qt instead of Python, and when they are destroyed they call
the destructor twice.

-->Jake

[SegundoBob]

On Sunday, February 23, 2014 2:01:06 PM UTC-8, Jacob Peck wrote:

More info: http://stackoverflow.com/questions/18416201/core-dump-with-pyqt4

The second answer seems to say that QObjects created without a parent
are owned by Qt instead of Python, and when they are destroyed they call
the destructor twice.

Beware of bad information on the Internet.

http://stackoverflow.com/questions/18416201/core-dump-with-pyqt4

QObjects constructed without parent are owned by Qt instead of PyQt,

This is exactly wrong--which you see if you follow the link it provides:

http://pyqt.sourceforge.net/Docs/PyQt4/qobject.html

QObject.__init__ (self, QObject parent = None)

The parent argument, if not None, causes self to be owned by Qt instead of PyQt.

--------

Your answers inspired me to find this:

http://downloads.conceptive.be/downloads/camelot/doc/sphinx/build/advanced/development.html

http://python-camelot.s3.amazonaws.com/gpl/default/pyqt/doc/advanced/development.html

(I think these pages differ only in the dates.)

This is complicated.  I have not convinced myself that it is internally consistent, much less correct.  I haven't convinced myself that the advice for avoiding these problems does avoid the problems, but it looks promising--and a major PITA.

python-camelot is an open source project of Conceptive Engineering.  I don't know how reliable their PyQt advice is.

[SegundoBob]

When I start Thunderbird (24.3.0) from a terminal, I always immediately get these messages on the terminal:

2014-03-05 12:45:16 ~
$ thunderbird

(process:8544): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(thunderbird:8544): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(thunderbird:8544): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(thunderbird:8544): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(thunderbird:8544): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
enigmail.js: Registered components
mimeVerify.jsm: module initialized

-----------

When I start Firefox (27.0.1) from a terminal, I always immediately get these messages on the terminal:

2014-03-05 12:49:02 ~
$ firefox

(process:8705): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(firefox:8705): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(firefox:8705): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(firefox:8705): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(firefox:8705): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised

------

Note that both Thunderbird and Firefox cause error:

GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

This is one of the errors that Leo-Editor causes.

So far as I know, neither Thunderbird nor Firefox cause error:

assertion 'GTK_IS_WIDGET (widget)' failed

This is by far the most frequent error caused by Leo-Editor.

My test system is:

Xubuntu64 13.10

[Edward K. Ream]

On Sun, Feb 23, 2014 at 3:24 PM, SegundoBob <segun...@gmail.com> wrote:

For years on three or four different Linux releases by three or four distributors, I've been seeing several instances per day of the following error messages to Leo-Editor's standard error file.  There is no other indication that anything is wrong.  Leo-Editor seems to run just fine when these errors occur.

​I don't see these message on Ubuntu.  What messages do you see with plugins disabled?

Edward

[Segundo Bob]

These messages only occur once or twice per day for me. That is, about
once out of 20 to 30 Leo-Editor sessions. I'm not certain at which
point in a session they occur, but they probably occur when a long
running session terminates.

I will need a few more days to determine if disabling plugins eliminates
the messages. So far it appears that disabling plugins does eliminate
the messages.

My testing is hampered by bug:

https://bugs.launchpad.net/leo-editor/+bug/1292207

--
Segundo Bob
Segun...@gmail.com

[SegundoBob]

On Wednesday, March 12, 2014 12:31:30 PM UTC-7, Edward K. Ream wrote:

​I don't see these message on Ubuntu.  What messages do you see with plugins disabled?

I have run for two and a half days with all plugins disabled, this is the only error that has occurred:

(process:2801): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

Attached are the stdout, stderr, and both stdout and stderr (which seems to indicate that the error occurred early in Leo-Editor initialization).

[Terry Brown]

On Sun, 16 Mar 2014 15:18:18 -0700 (PDT)
SegundoBob <segun...@gmail.com> wrote:

>
>
> On Wednesday, March 12, 2014 12:31:30 PM UTC-7, Edward K. Ream wrote:
> >
> >
> > ​I don't see these message on Ubuntu. What messages do you see
> > with plugins disabled?
> >
>
> I have run for two and a half days with all plugins disabled, this is
> the only error that has occurred:
>
> (process:2801): GLib-CRITICAL **: g_slice_set_config: assertion
> 'sys_page_size == 0' failed

I think these are errors in the interaction of GTk in the desktop, Qt,
and the window manager.

I see similar errors with other apps. firefox, for example. I think
it's just annoying chatter from Gtk.

Cheers -Terry

[SegundoBob]

I've finally discovered a test that for me causes a Gtk-CRITICAL error consistently.

I use my demo file for my "delete all children" function:  delAllChildren.leo  (attached).

Edit delAllChildren.leo with only plugin mod_scripting.py enabled.  Select node "@button dac" and hit Ctrl-B to execute the delete-all-children.  No Gtk-CRITICAL errors occur.  Now click the "dac" button.  This causes Gtk-CRITICAL errors to occur:

$ leomy delAllChildren.leo

** isPython3: False
Leo 4.11 final, build 042b3a51ba03 (branch: master), 2014-03-19 13:56:51
Python 2.7.5, qt version 4.8.4
linux2
setting leoID from os.getenv('USER'): 'bob06'
load dir: /home/ldi/git/leo-editor/leo/core
global config dir: /home/ldi/git/leo-editor/leo/config
home dir: /home/bob06
reading settings in /home/ldi/git/leo-editor/leo/config/leoSettings.leo
reading settings in /home/bob06/.leo/myLeoSettings.leo
Found /help
Abbreviations off
reading settings in /home/ldi/git/leo_misc/delAllChildren.leo
Abbreviations off

(python:2660): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

(python:2660): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed

------

For me, whenever I click the "dac" button, I get the two errors above; and whenever I execute the same code with Ctrl-B, I don't get the errors.  With all plugins disabled, there is no "dac" button and hence no errors.

[SegundoBob]

As you may have guessed from my posting on 2014-03-22, so far as I have been able to determine, the only time these Gtk-CRITICAL errors occur is when a button created by the mod_scripting.py plugin is clicked--and they occur every time such a button is clicked.

I enabled the trace at

/home/ldi/git/leo-editor/leo/core/LeoPyRef.leo#Code-->Qt gui-->@file ../plugins/qtGui.py-->Frame and component classes...-->class leoQtFrame-->class qtIconBarClass-->add (qtIconBarClass)

        def button_callback(c=c,command=command):
            g.trace('command',command.__name__)
            val = command()
            if c.exists:
                # c.bodyWantsFocus()
                c.outerUpdate()
            return val

And determined that the Gtk-CRITICAL errors occur after the button is clicked and before button_callback() is called.  That is, the errors occur in code that is not in Leo-Editor.  None the less, the mod_scripting.py plugin is certainly causing the errors.

Note that the errors are GTK errors, but Leo-Editor uses PyQt4, not GTK --- except for themes.  That is, the problem is probably caused by how the mod_scripting.py plugin "styles" its buttons.  I expect these errors to only occur on systems that are "GTK themed" such as the Xubuntu64 14.04 which I currently use.

These errors occur for Python 2.7 and Python 3.4.  For each button click using Python 2.7, I see two errors.  For each button click using Python 3.4, I see four errors.

I'm currently out of ideas for finding this bug.  I hope someone else will find this bug soon.  I don't know when I'll return to it.

[Edward K. Ream]

On Wed, May 14, 2014 at 9:00 PM, SegundoBob <segun...@gmail.com> wrote:
> As you may have guessed from my posting on 2014-03-22, so far as I have been
> able to determine, the only time these Gtk-CRITICAL errors occur is when a
> button created by the mod_scripting.py plugin is clicked--and they occur
> every time such a button is clicked.

Many thanks for this detailed description of the problem and its likely cause.

> And determined that the Gtk-CRITICAL errors occur after the button is
> clicked and before button_callback() is called. That is, the errors occur
> in code that is not in Leo-Editor. None the less, the mod_scripting.py
> plugin is certainly causing the errors.
>
> Note that the errors are GTK errors, but Leo-Editor uses PyQt4, not GTK ---
> except for themes. That is, the problem is probably caused by how the
> mod_scripting.py plugin "styles" its buttons. I expect these errors to only
> occur on systems that are "GTK themed" such as the Xubuntu64 14.04 which I
> currently use.

This is a strange one. Have you googled for ways of suppressing these
errors? No doubt these errors are quite annoying.

And just to confirm, you don't actually see any problem with the code
(except for the messages themselves), right?

Edward

[Segundo Bob]

On 05/20/2014 04:08 AM, Edward K. Ream wrote:
> Have you googled for ways of suppressing these
> errors?

Now I have. The only suggestion I found was a very bad suggestion:
redirect stderr to /dev/null. I doubt that there is any way to suppress
these errors. The glib developers refuse to fix the problem. See

https://bugzilla.gnome.org/show_bug.cgi?id=362749

> And just to confirm, you don't actually see any problem with the code
> (except for the messages themselves), right?

I have not observed any bad program behavior that I think is in any way
related to the GTK-Critical error messages. As is noted in the above
bugzilla thread, because glib does check for bad parameters, it renders
harmless otherwise fatal bugs in application code.

But as is noted in the above bugzilla thread and in several other
discussions on the Internet, the GTK-Critical error messages almost
certainly indicate that someone is calling GTK functions with bad
parameters. The mod_scripting.py is probably doing something that it
should not do. My best guess is that button styling is the problem.

--
Segundo Bob
Segun...@gmail.com

[Edward K. Ream]

On Tue, May 20, 2014 at 4:06 PM, Segundo Bob <segun...@gmail.com> wrote:

> I doubt that there is any way to suppress
> these errors. The glib developers refuse to fix the problem. See
>
> https://bugzilla.gnome.org/show_bug.cgi?id=362749

Imo, the attitude of the developers merits the sarcasm at the end, not
that it helps the OP :-) Hehe, I just barely refrained from saying so
on the glib list.

> ...the GTK-Critical error messages almost

> certainly indicate that someone is calling GTK functions with bad
> parameters. The mod_scripting.py is probably doing something that it
> should not do. My best guess is that button styling is the problem.

It's really hard to debug an error message that I don't see, on a
system that I don't have, and that nobody else can duplicate.

Maybe assigning stderr to /dev/null is the most reasonable workaround.

Anyone else have any other ideas? This is an issue that merits a solution.

Edward

[Segundo Bob]

On 05/22/2014 11:47 AM, Edward K. Ream wrote:
> This is an issue that merits a solution.

Yes, it merits a solution, but it is very low priority for me. Now that
I'm confident that the error messages are the only symptom, I can live
with the error messages. This problem has been around for several years
at least. I've learned to live with it.


--
Segundo Bob
Segun...@gmail.com

[Terry Brown]

On Sat, 22 Mar 2014 14:53:46 -0700 (PDT)
SegundoBob <segun...@gmail.com> wrote:

> I've finally discovered a test that for me causes a Gtk-CRITICAL
> error consistently.

Doesn't do so for me in Ubuntu 14.04. But I've seen Gtk-CRITICAL
errors before, makes me wonder if the problems in the Ubuntu
Qt <-> Gtk level, i.e. a particular uncommon but correct action in Leo
PyQt was firing the error before, but isn't now, because Ubuntu fixed
something in their PyQt, or in the way the window manager triggers GTk
actions, or some "below Leo" level thing.

I guess this makes sense up to the point where you say "I still see
them in 14.04".

... hmm, I guess I can try Unity instead of Xfce, but that would only
confirm my "below Leo" level theory.

Cheers -Terry

[Terry Brown]

On Thu, 22 May 2014 15:24:25 -0500
"'Terry Brown' via leo-editor" <leo-e...@googlegroups.com> wrote:

> On Sat, 22 Mar 2014 14:53:46 -0700 (PDT)
> SegundoBob <segun...@gmail.com> wrote:
>
> > I've finally discovered a test that for me causes a Gtk-CRITICAL
> > error consistently.
>
> Doesn't do so for me in Ubuntu 14.04. But I've seen Gtk-CRITICAL
> errors before, makes me wonder if the problems in the Ubuntu
> Qt <-> Gtk level, i.e. a particular uncommon but correct action in Leo
> PyQt was firing the error before, but isn't now, because Ubuntu fixed
> something in their PyQt, or in the way the window manager triggers GTk
> actions, or some "below Leo" level thing.
>
> I guess this makes sense up to the point where you say "I still see
> them in 14.04".
>
> ... hmm, I guess I can try Unity instead of Xfce, but that would only
> confirm my "below Leo" level theory.

Nope, doesn't do it in Unity either.

[Segundo Bob]

On 05/22/2014 01:24 PM, 'Terry Brown' via leo-editor wrote:
> Doesn't do so for me in Ubuntu 14.04.

Good for Leo-Editor. Bummer for me.

You tried the XFCE desktop (a.k.a. Xubuntu) and there were no error
messages. You tried the Unity desktop and no error messages.

Looks like this problem only exists for a very small number of users.
Maybe I'm the only one with the problem.

This is strange since it has existed for me for so long and through
several Linux distribution changes, but stranger things have happened.

Thanks for looking into this problem. I have no further ideas to
suggest at this time.

--
Segundo Bob
Segun...@gmail.com

[SegundoBob]

Terry,

The Gtk-CRITICAL errors are printed to stderr by Gtk/Glib code.  Hence, they never appear in the Leo-Editor log pane.  They only appear on the console.  Hence, to do the tests you must start Leo-Editor from a console and then you must look for the errors on the console.

This is so obvious to me that I may have failed to communicate it to you and others.

Respectfully,
SegundoBob

[Terry Brown]

No worries :-) it was obvious to me too. I'm fairly positive I've seen
Leo trigger these messages in the past, I've certainly seen them from
more apps. than just Leo, but I think they're very much a combination
of interactions between Ubuntu versions, window managers, desktop
themes, etc. etc.

Cheers -Terry


> Respectfully,
> SegundoBob
>

[Pangaea Flipped]

[Pangaea Flipped]

OK, i hope I'm not too late, the error comes from the fonts value in gtk set up, change your  system to oxygen and your fonts will follow, this is a gui issue not a python issue, i stumbled on it after error code i shut it down and said i'll deal with it later, changed my desktop and wham, jack came right up and running, still have a ton of x errors to figure out, but i was able to get hydrogen drum machine to load and come through my sound blaster live, hope it helps ...Pangaea

[Edward K. Ream]

On Fri, Jun 13, 2014 at 5:50 PM, Pangaea Flipped <dayto...@gmail.com> wrote:
> OK, i hope I'm not too late, the error comes from the fonts value in gtk set
> up, change your system to oxygen and your fonts will follow, this is a gui
> issue not a python issue, i stumbled on it after error code i shut it down
> and said i'll deal with it later, changed my desktop and wham, jack came
> right up and running, still have a ton of x errors to figure out, but i was
> able to get hydrogen drum machine to load and come through my sound blaster
> live, hope it helps ...Pangaea

Many thanks for this tip.

Edward