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 :)
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.
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)
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
(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
(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.
(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...
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.
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!
(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
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 ?
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
(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?
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 [...]
OK, I can reproduce that. Is it a regression, or did you just not notice it until now?
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 [...]
(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!
(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?
... 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
(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?
(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.
ok, opened as bug 1440434, closing this one.