Opened 7 years ago

Closed 7 years ago

#3242 closed defect (invalid)

Gui does not disply correctly and locks up when scrolling down to make alternative mapsets visible in d.vect and d.rast.

Reported by: ewcgrass Owned by: grass-dev@…
Priority: critical Milestone: 7.0.6
Component: wxGUI Version: 7.2.0
Keywords: Cc:
CPU: x86-64 Platform: Linux

Description

When scrolling down map lists in the map selection drop-down window in the first (Required) tab of d.vect and d.rast, the GUI locks up upon any of the additional mapsets that are made accessible (shown in blue in the GUI) being exposed in the GUI, except for the PERMANENT mapset, which appears already expanded and does not cause the problem. While so far as I can tell GUI lock-up may NOT occur about 5% to 10% of the time when only exposing the unexpanded additional mapsets, it appears to occur 100% of the time if the unexpanded mapsets are clicked upon. The additional mapsets only appear as unexpanded. The GUI also displays oddly on occasion, whereby when moved over GUI buttons the mouse pointer appears as a box with two arrows at 45 degrees, and the scroll bar in the above noted drop-down window fails to appear, such that scrolling can only be done using the mouse wheel.

Once locked up, trying to shut down GRASS the normal way is impossible because while the "Do you want to quit GRASS" window opens after clicking on the GUI's x (top-right corner), that window is also non-responsive.

When the GRASS GUI is locked up, Xorg uses 100% of one CPU core, but immediately drops to 0% after shutting GRASS down by typing Ctrl-D in the console.

I am also experiencing the blacked-out check-boxes which were reported elsewhere and are being dealt with upstream by M. Neteler re. the wxGTK3 repeated "Gtk-CRITICAL" warning bug. This leads me to question whether what I am describe in the first paragraph above may not also be related to wxGTK3??

I experience the very same defects in GRASS 7.2.0svn (r70142), which I have compiled myself, as well as with GRASS 7.0.4-2.fc25.x86_64, which I am running as supplied directly from the GRASS Fedora repository.

This problem became apparent only after upgrading from Fedora 21 to Fedora 25. All other computer functions seem to work correctly since the upgrade.

I am running kernel 4.8.15-300.fc25.x86_64, AMD Phenom II X4 processor, 16 GiB memory, Gnome 3.22 on X server, Nvidia GeForce GT 740 GPU with nvidia driver from rpmfusion.

Change History (22)

comment:1 by ewcgrass, 7 years ago

Sorry, in the heading "disply" should read "display".

I also failed to note that accessing mapsets via the "data" tab in the Map Layer window appears to function 100% correctly.

comment:2 by ewcgrass, 7 years ago

Fedora pushed wxGTK3 to 3.0.2-31 and Xorg-Xserver to 1.19.0-13 today, which appear to fix the blacked-out check-box issue. However, the problems with mouse pointer drawing and GUI lock up by the d.rast and d.vect map selection drop-down windows remain.

comment:3 by ewcgrass, 7 years ago

Oops, forgot to include this output from the terminal which comes up repeatedly when bringing up the d.rast and d.vect GUIs:

(wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton

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

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

comment:4 by annakrat, 7 years ago

Could you test wxpython demo, specifically ComboCtrl, TreeCtrl Popup? This should be the same widget.

in reply to:  4 ; comment:5 by neteler, 7 years ago

Replying to annakrat:

Could you test wxpython demo, specifically ComboCtrl, TreeCtrl Popup? This should be the same widget.

Note: The demos are in /usr/share/doc/wxPython-docs/demo/ - so for example:

python /usr/share/doc/wxPython-docs/demo/TreeMixin.py

comment:6 by ewcgrass, 7 years ago

I ran TreeMixin.py per your example, then ComboCtrl.py and TreeCtrl.py. Everything in the windows that opened appeared to run fine. This is a copy of the messages that came up on the terminal:

[rick@localhost ~]$ python /usr/share/doc/wxPython-docs/demo/TreeMixin.py Python 2.7.12 (default, Sep 29 2016, 12:52:02) [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] wx.version: 3.0.2.0 gtk3 (classic)

(TreeMixin.py:520): Gtk-CRITICAL : gtk_widget_set_size_request: assertion 'height >= -1' failed

(TreeMixin.py:520): Gtk-CRITICAL : gtk_widget_get_preferred_width_for_height: assertion 'height >= 0' failed

(TreeMixin.py:520): Gtk-WARNING : gtk_widget_size_allocate(): attempt to allocate widget with width 18 and height -8 Traceback (most recent call last):

File "/usr/share/doc/wxPython-docs/demo/TreeMixin.py", line 199, in OnPageChanged

oldTree = self.GetPage(event.OldSelection)

File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk3/wx/_core.py", line 13536, in GetPage

return _core_.BookCtrlBase_GetPage(*args, kwargs)

ValueError: in method 'BookCtrlBase_GetPage', expected argument 2 of type 'size_t' Traceback (most recent call last):

File "/usr/share/doc/wxPython-docs/demo/TreeMixin.py", line 199, in OnPageChanged

oldTree = self.GetPage(event.OldSelection)

File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk3/wx/_core.py", line 13536, in GetPage

return _core_.BookCtrlBase_GetPage(*args, kwargs)

ValueError: in method 'BookCtrlBase_GetPage', expected argument 2 of type 'size_t'

[rick@localhost ~]$ python /usr/share/doc/wxPython-docs/demo/ComboCtrl.py Python 2.7.12 (default, Sep 29 2016, 12:52:02) [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] wx.version: 3.0.2.0 gtk3 (classic) 17:36:36: ListCtrlComboPopup.Init 17:36:36: ListCtrlComboPopup.LazyCreate 17:36:36: ListCtrlComboPopup.Create 17:36:41: ListCtrlComboPopup.GetAdjustedSize: 250, 400, 934 17:36:41: ListCtrlComboPopup.OnPopup 17:36:41: ListCtrlComboPopup.SetStringValue 17:36:44: ListCtrlComboPopup.GetStringValue 17:36:44: ListCtrlComboPopup.SetStringValue 17:36:44: ListCtrlComboPopup.OnDismiss

(ComboCtrl.py:568): Pango-CRITICAL : pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed

(ComboCtrl.py:568): Pango-CRITICAL : pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed

(ComboCtrl.py:568): Pango-CRITICAL : pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed

(ComboCtrl.py:568): Pango-CRITICAL : pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed

[rick@localhost ~]$ python /usr/share/doc/wxPython-docs/demo/TreeCtrl.py Python 2.7.12 (default, Sep 29 2016, 12:52:02) [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] wx.version: 3.0.2.0 gtk3 (classic) 17:37:27: OnItemExpanded: Item 3 17:37:29: OnItemExpanded: item 3-b 17:37:31: OnSelChanged: item 3-b-0 17:37:35: OnItemExpanded: item 3-d 17:37:38: OnSelChanged: item 3-d-1 17:37:41: OnSelChanged: The Root Item 17:37:44: OnItemExpanded: Item 0 17:37:46: OnSelChanged: item 0-b 17:37:47: OnItemExpanded: item 0-b 17:37:48: OnSelChanged: item 0-b-1 [rick@localhost ~]$

Version 0, edited 7 years ago by ewcgrass (next)

comment:7 by neteler, 7 years ago

This is a bug in wxGTK3, not in GRASS GIS. Please report it here:

https://bugzilla.redhat.com/buglist.cgi?component=wxGTK3&list_id=6923830&product=Fedora

The maintainer is very fast, so it is worthwhile to report it there.

Unfortunately there is still several bugs in wxGTK3, but reporting them will help.

in reply to:  5 ; comment:8 by annakrat, 7 years ago

Have you specifically tested TreeCtrl Popup widet in ComboCtrl.py? I just want to make sure, because there is multiple widgets in this demo. The errors in your output are unrelated to this widget. Markus, if you have similar configuration, can you confirm this? I still think it's something in wxwidgets.

in reply to:  8 ; comment:9 by neteler, 7 years ago

Replying to annakrat:

Have you specifically tested TreeCtrl Popup widet in ComboCtrl.py? I just want to make sure, because there is multiple widgets in this demo. The errors in your output are unrelated to this widget. Markus, if you have similar configuration, can you confirm this? I still think it's something in wxwidgets.

I have now tried myself (wxGTK3-3.0.2-31.fc24.x86_64):

python /usr/share/doc/wxPython-docs/demo/ComboCtrl.py
Python 2.7.12 (default, Sep 29 2016, 13:30:34) 
[GCC 6.2.1 20160916 (Red Hat 6.2.1-2)]
wx.version: 3.0.2.0 gtk3 (classic)
23:23:28: ListCtrlComboPopup.Init
23:23:28: ListCtrlComboPopup.LazyCreate
23:23:28: ListCtrlComboPopup.Create
23:23:32: ListCtrlComboPopup.GetAdjustedSize: 250, 400, 621
23:23:32: ListCtrlComboPopup.OnPopup
23:23:32: ListCtrlComboPopup.SetStringValue
23:23:33: ListCtrlComboPopup.GetStringValue
23:23:33: ListCtrlComboPopup.SetStringValue
23:23:33: ListCtrlComboPopup.OnDismiss

... this one seems to behave ok!

in reply to:  9 ; comment:10 by annakrat, 7 years ago

Replying to neteler:

... this one seems to behave ok!

And the one in GRASS?

comment:11 by ewcgrass, 7 years ago

I have tried TreeClrl, ComboCtr, as well as TreeListCtrl, ComboTreeBox and ComboBox, and all seemed to behave ok.

comment:12 by ewcgrass, 7 years ago

I have reported this to Red Hat Bugzilla as Bug 1411165 (https://bugzilla.redhat.com/show_bug.cgi?id=1411165), with cross reference to this GRASS bug report.

Last edited 7 years ago by neteler (previous) (diff)

in reply to:  10 comment:13 by neteler, 7 years ago

Replying to annakrat:

Replying to neteler:

... this one seems to behave ok!

And the one in GRASS?

So:

d.rast --ui

works fine, but

d.vect --ui

is killing the CPU, flooding the terminal with

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

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

(forms.py:23008): Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries
...
Last edited 7 years ago by neteler (previous) (diff)

comment:14 by ewcgrass, 7 years ago

FYI, Scott Talbert has started to look at issue on Red Hat Bugzilla.

In additional trials, errors flooding terminal appears to be more related to d.vect than to d.rast.

However, problem continues when creating new map displays in both d.vect and d.rast. Also, the problem is intermittent when double-clicking on an already displayed map layer in the layer manager, which opens say, d.vect, for a displayed vector map. Then often (but not always) the scroll bar does not display in the map selection drop-down window (must scroll using mouse wheel). When scrolled all the way to the bottom of the drop-down window to expose the additional mapsets (in blue, not expanded), all usually appears fine. However, sometimes little arrow (triangle) to the left of the mapset name appears and the mapset can be expanded, while other times the triangle does not appear and clicking on the additional mapset name locks up the GUI, accompanied as usual by 100% usage of one CPU core by Xorg until stopping GRASS with Ctrl-D in the terminal.

comment:15 by annakrat, 7 years ago

I ran Fedora 25 in virtual machine and I can't reproduce any of the problems. The problem with the missing triangle you just described doesn't seem to be related to GRASS.

in reply to:  15 comment:16 by neteler, 7 years ago

Replying to annakrat:

I ran Fedora 25 in virtual machine and I can't reproduce any of the problems. The problem with the missing triangle you just described doesn't seem to be related to GRASS.

FYI: I just updated to Fedora 25 and the CPU issue is gone. Will check if any other troubles remain.

comment:17 by neteler, 7 years ago

Being a Fedora 25 user, I believe that the high CPU load issues result from wxGTK3, see

https://bugzilla.redhat.com/buglist.cgi?component=wxGTK3&product=Fedora&list_id=7055558

I'll keep an eye on this and file future reports there.

Anything left open here from the GRASS GIS side?

comment:18 by mlennert, 7 years ago

Can we close this ?

comment:19 by ewcgrass, 7 years ago

This problem still exists and can be a real game stopper when it occurs during a long working session.

Scott Talbert on Redhat Bugzilla (Bug # 1411165) suggests (comment 3) that message flooding may be a widget sizing issue that needs to be fixed in GRASS. Nothing more appears to have been done upstream since Markus last commented on 10 January 2017. Your thoughts Markus?

in reply to:  19 ; comment:20 by neteler, 7 years ago

Replying to ewcgrass:

This problem still exists and can be a real game stopper when it occurs during a long working session.

Yes, it also eats the laptop battery....

Scott Talbert on Redhat Bugzilla (Bug # 1411165) suggests (comment 3) that message flooding may be a widget sizing issue that needs to be fixed in GRASS. Nothing more appears to have been done upstream since Markus last commented on 10 January 2017. Your thoughts Markus?

I have opened a new bug report for this upstream for high CPU usage: https://bugzilla.redhat.com/show_bug.cgi?id=1440434

in reply to:  20 comment:21 by neteler, 7 years ago

I found a wxGTK demo which behaves similarly - CPU usage at 100%:

cd /usr/share/doc/wxPython-docs/demo/
python run.py Calendar.py
# --> click button, CPU will go up

(from wxGTK3-3.0.2-32.fc25.x86_64 + wxPython-docs-3.0.2.0-11.fc25.noarch)

Do we use the same widget(s)?

comment:22 by neteler, 7 years ago

Resolution: invalid
Status: newclosed

The high CPU problem has been fixed: wxGTK3-3.0.3 was backported to Fedora 25 and 26 (see https://bugzilla.redhat.com/show_bug.cgi?id=1440434).

The annoying warnings "Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton" are unrelated and need to be fixed in GRASS GIS itself (different bug report).

Closing this report (I have chosen "invalid" since the reason was wxGTK3). Feel free to reopen if anything in this report was not fixed.

Note: See TracTickets for help on using tickets.