Opened 3 years ago

Closed 3 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 Changed 3 years ago by ewcgrass

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 Changed 3 years ago by ewcgrass

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 Changed 3 years ago by ewcgrass

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 Changed 3 years ago by annakrat

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

comment:5 in reply to:  4 ; Changed 3 years ago by neteler

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 Changed 3 years ago by ewcgrass

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 ~]$ 

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

comment:7 Changed 3 years ago by neteler

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.

comment:8 in reply to:  5 ; Changed 3 years ago by 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.

comment:9 in reply to:  8 ; Changed 3 years ago by neteler

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!

comment:10 in reply to:  9 ; Changed 3 years ago by annakrat

Replying to neteler:

... this one seems to behave ok!

And the one in GRASS?

comment:11 Changed 3 years ago by ewcgrass

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

comment:12 Changed 3 years ago by ewcgrass

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 3 years ago by neteler (previous) (diff)

comment:13 in reply to:  10 Changed 3 years ago by neteler

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 3 years ago by neteler (previous) (diff)

comment:14 Changed 3 years ago by ewcgrass

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 Changed 3 years ago by 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.

comment:16 in reply to:  15 Changed 3 years ago by neteler

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 Changed 3 years ago by neteler

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 Changed 3 years ago by mlennert

Can we close this ?

comment:19 Changed 3 years ago by ewcgrass

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?

comment:20 in reply to:  19 ; Changed 3 years ago by neteler

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

comment:21 in reply to:  20 Changed 3 years ago by neteler

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 Changed 3 years ago by neteler

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.