Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1364580 - wxGTK3 warnings "flooding" the terminal
Summary: wxGTK3 warnings "flooding" the terminal
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: wxGTK3
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Scott Talbert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-05 19:58 UTC by markusN
Modified: 2017-04-08 22:19 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-08 22:19:11 UTC


Attachments (Terms of Use)

Description markusN 2016-08-05 19:58:21 UTC
After updating to F24, I get lots of such issues with wxPython-3.0.2.0-10.fc24.x86_64 in GRASS GIS 7.

(an upstream report is at https://trac.osgeo.org/grass/ticket/3117; they suggested to report here)


At startup of a wx window (graphical output): tons of these warnings appear:

(main.py:6274): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton
...


When doing wx window resize: many of these warnings are printed:

(main.py:6274): Gtk-WARNING **: Allocating size to wxPizza 0x558b2ed9d9a0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

This pollutes the terminal a lot...

Version-Release number of selected component (if applicable):
wxPython-3.0.2.0-10.fc24.x86_64

I have self-compiled GRASS GIS as I do for decades :)

Comment 1 Scott Talbert 2016-08-06 01:25:54 UTC
Is there a way to run that "d.mon wx0" command more directly?  I would like to run it under GDB but it seems like it's a separate process that gets started.

Comment 2 markusN 2016-08-06 07:37:49 UTC
Using 
ps -aef | grep grass

you will see one process "...gui/wxpython/mapdisp/main.py..." running to which
GDB could be attached? 

(If that doesn't work I'll check with the GRASS devs who wrote this command)

Comment 3 markusN 2016-08-06 07:44:01 UTC
I just noted that starting "g.gui.mapswipe" (a Python script, looks like this [1]) also leads to these Gtk-CRITICAL messages.

[1] https://grass.osgeo.org/grass72/manuals/g.gui.mapswipe.html

Comment 4 markusN 2016-08-06 22:01:23 UTC
(In reply to Scott Talbert from comment #1)
> Is there a way to run that "d.mon wx0" command more directly?  I would like
> to run it under GDB but it seems like it's a separate process that gets
> started.

Would this help?

# needed to generate a PID
d.mon wx0

# one line:
python `g.gisenv GISBASE`/gui/wxpython/mapdisp/main.py wx0 `g.gisenv GISDBASE,LOCATION_NAME,MAPSET sep=/`/.tmp/$HOSTNAME/MONITORS/wx0 640 480 0

Comment 5 Scott Talbert 2016-09-07 23:10:51 UTC
(In reply to markusN from comment #0)
> At startup of a wx window (graphical output): tons of these warnings appear:
> 
> (main.py:6274): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size
> >= 0' failed in GtkCheckButton

This error can be avoided by making the window wider, e.g.:
d.mon wx0 width=700

It is complaining that there isn't enough space for the checkbox.

I'm not sure yet about the wxPizza errors.

Comment 6 markusN 2016-09-14 21:03:04 UTC
(In reply to Scott Talbert from comment #5)
> (In reply to markusN from comment #0)
> > At startup of a wx window (graphical output): tons of these warnings appear:
> > 
> > (main.py:6274): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size
> > >= 0' failed in GtkCheckButton
> 
> This error can be avoided by making the window wider, e.g.:
> d.mon wx0 width=700

Thanks for the hint, fixed in GRASS GIS trunk, 7.2.svn (for 7.2.0) and 7.0.svn (for 7.0.5).

> It is complaining that there isn't enough space for the checkbox.
> 
> I'm not sure yet about the wxPizza errors.

... also flooding the terminal...

Comment 7 Scott Talbert 2016-11-15 01:20:08 UTC
I think the wxPizza errors might have been fixed by one of the patches in wxGTK3-3.0.2-29.  At least I can't reproduce them any more.

Comment 8 markusN 2016-11-17 21:49:17 UTC
GRASS 7.2.svn (nc_climate_spm_2000_2012):~ > d.mon wx0
GRASS 7.2.svn (nc_climate_spm_2000_2012):~ > 

# enlarging the window
GRASS 7.2.svn (nc_climate_spm_2000_2012):~ > 
(main.py:2407): Gtk-WARNING **: Allocating size to wxPizza 0x55b09a36f9d0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(main.py:2407): Gtk-WARNING **: Allocating size to wxPizza 0x55b09a36f9d0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(main.py:2407): Gtk-WARNING **: Allocating size to wxPizza 0x55b09a36f9d0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(main.py:2407): Gtk-WARNING **: Allocating size to wxPizza 0x55b09a36f9d0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(main.py:2407): Gtk-WARNING **: Allocating size to wxPizza 0x55b09a36f9d0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

The package is wxGTK3-3.0.2-26.fc24.x86_64 - where would I get wxGTK3-3.0.2-29? Thanks!

Comment 9 Scott Talbert 2016-11-17 22:05:51 UTC
(In reply to markusN from comment #8)
> The package is wxGTK3-3.0.2-26.fc24.x86_64 - where would I get
> wxGTK3-3.0.2-29? Thanks!

It's in updates-testing:

wxGTK3-3.0.2-29.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-da57f5c618

Comment 10 markusN 2016-11-19 10:23:08 UTC
Great, the "wxPizza" msg is gone with that update.

Still I get these two messages:

GRASS 7.2.svn (nc_spm_08_grass7):~ > g.gui
Launching <wxpython> GUI in the background, please wait...
GRASS 7.2.svn (nc_spm_08_grass7):~ > 11:18:10 AM: Debug: Failed to connect to session manager: SESSION_MANAGER environment variable not defined
(wxgui.py:11292): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar


For the former msg, I found
http://trac.wxwidgets.org/ticket/16024

The latter is probably here:
http://trac.wxwidgets.org/ticket/17585
https://bugzilla.gnome.org/show_bug.cgi?id=754976

I also found some patch here (dunno if to be implemented in GRASS GIS like that):
https://sourceforge.net/p/scintilla/code/ci/63f89102ae1608777ddb9a22d1d644af7c9320db/

Should I anyway leave positive feedback in https://bodhi.fedoraproject.org/updates/FEDORA-2016-da57f5c618 ?

Comment 11 markusN 2016-11-26 14:30:44 UTC
Unfortunately a new problem occurred (happens in GRASS GIS):

(wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries

(wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries

(wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries

(wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries

(wxgui.py:20719): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton

(wxgui.py:20719): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton

(wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries

The upper one even hammers the CPU... I am using
wxGTK3-3.0.2-29.fc24.x86_64

It was earlier also reported here in Bug 1304681

Comment 12 Scott Talbert 2016-11-26 17:39:24 UTC
(In reply to markusN from comment #11)
> Unfortunately a new problem occurred (happens in GRASS GIS):
> 
> (wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously
> requested, giving up after 4 tries
> 
> (wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously
> requested, giving up after 4 tries
> 
> (wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously
> requested, giving up after 4 tries
> 
> (wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously
> requested, giving up after 4 tries
> 
> (wxgui.py:20719): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion
> 'size >= 0' failed in GtkSpinButton
> 
> (wxgui.py:20719): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion
> 'size >= 0' failed in GtkSpinButton
> 
> (wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously
> requested, giving up after 4 tries
> 
> The upper one even hammers the CPU... I am using
> wxGTK3-3.0.2-29.fc24.x86_64
> 
> It was earlier also reported here in Bug 1304681

How do you reproduce this in GRASS?

Comment 13 markusN 2016-11-26 17:51:37 UTC
You can reproduce it like this (here via "shortcut" to user interface for easy reproduction):

GRASS 7.2.0svn (nc_spm_08_grass7):~ > d.vect --ui

(forms.py:20410): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton

(forms.py:20410): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton

(forms.py:20410): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton

(forms.py:20410): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries

(forms.py:20410): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries

(forms.py:20410): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries

(forms.py:20410): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries

(forms.py:20410): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries

[...]

Comment 14 Scott Talbert 2016-11-27 15:26:39 UTC
OK, I can reproduce that.  Is it a regression, or did you just not notice it until now?

Comment 15 markusN 2016-11-27 17:20:11 UTC
It is a new problem which I never got: CPU at 100%

[neteler@oboe ]$ top

top - 18:18:25 up 3 days, 21:55,  2 users,  load average: 0.65, 0.25, 0.13
Tasks: 237 total,   2 running, 235 sleeping,   0 stopped,   0 zombie
%Cpu(s): 35.5 us,  2.5 sy,  0.0 ni, 60.4 id,  1.0 wa,  0.4 hi,  0.2 si,  0.0 st
KiB Mem :  3929956 total,   114448 free,  1821816 used,  1993692 buff/cache
KiB Swap:  3932156 total,  3487340 free,   444816 used.  1583088 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 3846 neteler   20   0 1022696 100392  55380 R  99.3  2.6   0:26.44 python
 1131 root      20   0  726276 195008 178732 S  26.9  5.0  60:12.59 Xorg
 3628 neteler   20   0  680488  33468  16884 S  13.3  0.9   4:33.52 xfce4-terminal
 1859 neteler   20   0 10.803g 1.000g 115700 S   3.7 26.7 304:13.13 firefox
 1455 neteler   20   0  491200  12608   9240 S   1.7  0.3   0:58.18 xfwm4
[...]

Comment 16 markusN 2017-01-10 23:10:00 UTC
(In reply to markusN from comment #11)
> Unfortunately a new problem occurred (happens in GRASS GIS):
> 
> (wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously
> requested, giving up after 4 tries
> 
> (wxgui.py:20719): Gdk-WARNING **: gdk-frame-clock: layout continuously
> requested, giving up after 4 tries

[...]

> The upper one even hammers the CPU... I am using
> wxGTK3-3.0.2-29.fc24.x86_64

I just updated to F25 and the CPU issue is gone (i.e. wxGTK3-3.0.2-31.fc25.x86_64). Nice!

Comment 17 Scott Talbert 2017-01-11 00:47:54 UTC
(In reply to markusN from comment #16)
> I just updated to F25 and the CPU issue is gone (i.e.
> wxGTK3-3.0.2-31.fc25.x86_64). Nice!

Great!  Do you think that we can close this ticket, now?

Comment 18 markusN 2017-01-14 17:24:26 UTC
... I spoke to soon: Having done a fresh GRASS GIS 7.2.svn recompile on F25, the standard GUI (g.gui) starts a python process with high CPU usage (d.vect now behaves).

In the terminal I see:

(wxgui.py:802): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar


strace of the python process shows:

...
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="5 \4\0\301K\224\1II\224\1\261\0\27\0\212\4\6\0\302K\224\1\301K\224\1&\0\0\0"..., iov_len=16372}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 16372
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\212\4\6\0~L\224\1}L\224\1&\0\0\0\0\4\0\0\1\0\0\0\212\32\7\0\0\0\0\0"..., iov_len=16380}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 16380
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\212\32\7\0\0L\224\1:M\224\1\0\0\0\0\0\0\0\0\0\0\0\0\261\0\27\0\212\32\7\0"..., iov_len=16384}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 16384
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\212\32\7\0\1L\224\1\366M\224\1\350\350\350\350\347\347\377\377\0\0\0\0\261\0\27\0005\10\4\0"..., iov_len=16384}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 16384
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="5\10\4\0\263N\224\1\321G\224\1\261\0\27\0\212\4\6\0\264N\224\1\263N\224\1$\0\0\0"..., iov_len=16372}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 16372
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\212\4\6\0pO\224\1oO\224\1$\0\0\0\0\4\0\0\1\0\0\0\212\32\7\0\0\0\0\0"..., iov_len=16380}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 16380
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="\212\32\7\0\0O\224\1,P\224\1\0\0\0\0\0\0\0\0\0\0\0\0\261\0\27\0\212\10\t\0"..., iov_len=16384}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 16384
recvmsg(3, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
---

Closing the g.gui eliminates this python process.
Note that I was only *opening* the GUI, not even loading a map.

If needed, I made an (S)RPM of GRASS GIS 7.2.0:
https://copr.fedoraproject.org/coprs/neteler/grass72

Comment 19 markusN 2017-04-06 13:08:45 UTC
(In reply to markusN from comment #18)
> ... I spoke to soon: Having done a fresh GRASS GIS 7.2.svn recompile on F25,
> the standard GUI (g.gui) starts a python process with high CPU usage

... this is still an issue (freshly installed F25 maschine) and rather ruins the performance.
Shall I open a separate ticket for this problem?

Comment 20 Scott Talbert 2017-04-06 19:21:03 UTC
(In reply to markusN from comment #19)
> (In reply to markusN from comment #18)
> > ... I spoke to soon: Having done a fresh GRASS GIS 7.2.svn recompile on F25,
> > the standard GUI (g.gui) starts a python process with high CPU usage
> 
> ... this is still an issue (freshly installed F25 maschine) and rather ruins
> the performance.
> Shall I open a separate ticket for this problem?

Yes, I think we've long since digressed from the original problem.

Comment 21 markusN 2017-04-08 22:19:11 UTC
ok, opened as bug 1440434, closing this one.


Note You need to log in before you can comment on or make changes to this bug.