[Bug] Windows 8.4.0dev cannot launch GUI with error in gui\wxpython\lmgr\statusbar.py

[echoix]

Describe the bug

I applied the changes from #3732 in a fresh installation in windows sandbox, since the nightly 8.4-313-f4d8c62ac-1 (for commit f4d8c62) didn't include the yet unmerged #3732.

I still get another error prevent from launching the GUI, and when I enter g.gui wxpython, I can get a stack trace mentioning the statusbar.py file, with gs.find_file keyerror: 'name'

To reproduce

1. Install the grass-dev nightly from OSGeo4W
2. Launch grass 8.4.0dev
3. Wait for the console+splash screen to appear
4. Wait for the splash screen to disappear
5. GUI never launches even after minutes.
6. Force launching gui by typing g.gui wxpython in the grass console.
7. See error.

Expected behavior

GRASS GUI is usable on windows at release

Screenshots

Starting GRASS GIS...
WARNING: Concurrent mapset locking is not supported on Windows

          __________  ___   __________    _______________
         / ____/ __ \/   | / ___/ ___/   / ____/  _/ ___/
        / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
       / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
       \____/_/ |_/_/  |_/____/____/   \____/___//____/

Welcome to GRASS GIS 8.4.0dev (exported)
GRASS GIS homepage:                      https://grass.osgeo.org
This version running through:            Command Prompt (C:\Windows\system32\cmd.exe)
Help is available with the command:      g.manual -i
See the licence terms with:              g.version -c
See citation options with:               g.version -x
If required, restart the GUI with:       g.gui wxpython
When ready to quit enter:                exit

Launching <wxpython> GUI in the background, please wait...
Microsoft Windows [Version 10.0.22621.3593]
(c) Microsoft Corporation. All rights reserved.

C:\Users\WDAGUtilityAccount\Documents>g.gui
Launching <wxpython> GUI in the background, please wait...
wxdigit.py: Could not load grass_vector.8.4.
wxdigit.py: Could not load grass_vector.8.4.
wxnviz.py: Could not load grass_g3d.8.4.
Traceback (most recent call last):
  File "C:\OSGeo4W\apps\Python312\Lib\site-packages\wx\core.py", line 3427, in <lambda>
    lambda event: event.callable(*event.args, **event.kw) )
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\OSGeo4W\apps\grass\grass84/gui/wxpython/wxgui.py", line 93, in show_main_gui
    mainframe = GMFrame(
                ^^^^^^^^
  File "C:\OSGeo4W\apps\grass\grass84\gui\wxpython\main_window\frame.py", line 184, in __init__
    self.BuildPanes()
  File "C:\OSGeo4W\apps\grass\grass84\gui\wxpython\main_window\frame.py", line 571, in BuildPanes
    self.statusbar = SbMain(parent=self, giface=self._giface)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\OSGeo4W\apps\grass\grass84\gui\wxpython\lmgr\statusbar.py", line 39, in __init__
    self.mask = SbMask(self.widget, self.giface)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\OSGeo4W\apps\grass\grass84\gui\wxpython\lmgr\statusbar.py", line 89, in __init__
    self.Refresh()
  File "C:\OSGeo4W\apps\grass\grass84\gui\wxpython\lmgr\statusbar.py", line 127, in Refresh
    if gs.find_file(
       ^^^^^^^^^^^^^
KeyError: 'name'

C:\Users\WDAGUtilityAccount\Documents>g.version
GRASS 8.4.0dev (2024)

C:\Users\WDAGUtilityAccount\Documents>g.version --help
Displays GRASS GIS version info.

Usage:
 g.version [-cxbreg] [--help] [--verbose] [--quiet] [--ui]

Flags:
  -c   Print also the copyright message
  -x   Print also the citation options
  -b   Print also the build information
  -r   Print also the GIS library revision number and date
  -e   Print also extended info for additional libraries
  -g   Print info in shell script style (including Git reference commit)

C:\Users\WDAGUtilityAccount\Documents>g.version -breg
version=8.4.0dev
date=2024
revision=exported
build_date=2024-04-14
build_platform=x86_64-w64-mingw32
build_off_t_size=8

./configure --host=x86_64-w64-mingw32 --with-libs=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/lib /C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/bin --with-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --libexecdir=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/bin --prefix=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/apps/grass --bindir=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/bin --includedir=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --with-opengl=windows --without-x --with-cxx --enable-shared --enable-largefile --with-fftw --with-freetype --with-freetype-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include/freetype2 --with-proj-share=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/share/proj --with-proj-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --with-proj-libs=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/lib --with-postgres --with-postgres-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --with-postgres-libs=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/lib --with-gdal=/c/src/osgeo4w/src/grass-dev/grass/mswindows/osgeo4w/gdal-config --with-geos=/c/src/osgeo4w/src/grass-dev/grass/mswindows/osgeo4w/geos-config --with-sqlite --with-sqlite-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --with-sqlite-libs=/c/src/osgeo4w/src/grass-dev/grass/mswindows/osgeo4w/lib --with-regex --with-nls --with-zstd --with-odbc --with-blas --with-lapack --with-lapack-includes=/mingw64/include --with-openmp --with-cairo --with-cairo-includes=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/include --with-cairo-ldflags=-L/c/src/osgeo4w/src/grass-dev/grass/mswindows/osgeo4w/lib -lcairo --with-bzlib --with-liblas=/c/src/osgeo4w/src/grass-dev/grass/mswindows/osgeo4w/liblas-config --with-netcdf=/C/src/osgeo4w/src/GRASS-~1/osgeo4w/osgeo4w/bin/nc-config --without-pdal host_alias=x86_64-w64-mingw32
libgis_revision=8.4.0dev
libgis_date=2024-04-13T22:45:54+00:00
proj=9.4.0
gdal=3.8.5
geos=3.12.1
sqlite=3.45.1

C:\Users\WDAGUtilityAccount\Documents>

System description

• Operating System: Windows 11 22H2 in windows sandbox
• GRASS GIS version: 8.4dev nightly from OSGeo4W, 8.4-313-f4d8c62ac-1, + change the file from wxGUI/history: Fix date formatting #3732 (see copied console)

Additional context

Before trying nightly 8.4-313-..., I tried 8.4-312-75375c90a-1 (for commit 75375c9), and in fact without patching 8.4-313-... and 8.4-312-..., on windows sandbox I get this error, while on my normal OS grass dev installation, with both unpatched I get the bug from #3726.

[echoix]

What's strange is that I only get it from a fresh install/environment, not from updating my current real OS OSGeo4w installation + patching. Is it something to do that some files/gisbase are not created yet on first launch after a new install and don't get noticed when developping?

[petrasovaa]

What do you get when you run g.findfile element=cell file=MASK and g.gisenv?

[echoix]

I'll try tomorrow, it's a good idea. I managed to understand how to step through all initialization code+the called subprocess within vscode, inside windows sandbox and the osgeo4w installation of grass. I ended up getting at the point were it fails, and it's like the stack trace.

What's weird was that in these lines:

grass/gui/wxpython/lmgr/statusbar.py

Lines 125 to 133 in b0a00b4

	def Refresh(self):
	"""Show mask in the statusbar if mask file found"""
	if gs.find_file(
	name=self.mask_layer, element="cell", mapset=gs.gisenv()["MAPSET"]
	)["name"]:
	self.Show()
	else:
	self.Hide()

The result of gs.find_file() before the square brackets indexing was effectively None, so indexing none would be a problem. However gs.gisenv()["MAPSET"] seemed ok, it was the string PERMANENT.

[echoix]

But thinking about it, I might have an idea for this bug and #3739. Since the revision info and library (libgis) build dates are reporting outdated, and that at the beginning of the trace it mentions three libraries that can't be loaded, is it possible that the OSGeo4W build are built in a clean environment, and/or only do incremental compilation, and/or keep the repo cloned, and don't clean completely the file tree, ie either make libsclean isn't called or doesn't clean correctly everything?

I found some alternative osgeo4w builds (https://wingrass.fsv.cvut.cz/grass84/osgeo4w/), and I think I found how to use them. So since I finished going through the debugging (finding out how to set it up was the longest), I want to flush the windows sandbox (close it and reopen it), and start again with that alternative package from the OSGeo4W installer, and see if the results are the same. If so, I'll also try the standalone windows builds from https://wingrass.fsv.cvut.cz/grass84/ and compare too.

[echoix]

What do you get when you run g.findfile element=cell file=MASK and g.gisenv?

@petrasovaa I think you've got something:

On a fresh install of 8.4-313-f4d8...-1 (fresh sandbox), running g.gisenv:

C:\Users\WDAGUtilityAccount\Documents>g.gisenv
GISDBASE=C:\Users\WDAGUtilityAccount\Documents\grassdata
LOCATION_NAME=world_latlong_wgs84
MAPSET=PERMANENT
GUI=wxpython
LAST_MAPSET_PATH=C:\Users\WDAGUtilityAccount\Documents\<UNKNOWN>\<UNKNOWN>
PID=2276
GUI_PID=3652

But g.findfile can't find gdal308.dll, showing the error box in the screenshot.

But on another fresh sandbox, downloading https://wingrass.fsv.cvut.cz/grass84/osgeo4w/grass-daily-8.4.0dev-55b2a2bccc-78.tar.bz2, predownloading (without installing) the requirements of the OSGeo4W grass-dev packages, then installing from local dir everything except grass-dev, then installing this grass-daily, this one works fine (except the formatting string in the history file), that works for the first time (like before I filed #3726, since no history existed yet).

So I'm still tending towards a build issue rather than code issue. Maybe both?

[echoix]

Installing back gdal308-runtime (not automatically depended by/installed by the grass-dev package),

We get a launching GRASS GUI:

So definitely a packaging/build issue from what I know.

[hellik]

Installing back gdal308-runtime (not automatically depended by/installed by the grass-dev package),

We get a launching GRASS GUI:

So definitely a packaging/build issue from what I know.

It's a packaging issue

@landam

[agiudiceandrea]

@echoix, the gdal308/gdal309 OSGeo4W packaging issue is fixed now since grass-dev-8.4-314-f3ccff668-1.

[echoix]

@echoix, the gdal308/gdal309 OSGeo4W packaging issue is fixed now since grass-dev-8.4-314-f3ccff668-1.

I'm not available right now to test it again, but will try again later

[echoix]

I was able to retry with grass-dev 8.4-314-xxxxxx-1, and it is effectively solved. I hope it isn't transient, and an intentional fix (to some code or the build environment) was applied.

[agiudiceandrea]

I hope it isn't transient, and an intentional fix (to some code or the build environment) was applied.

I don't know. I think @jef-n knows for sure.

[echoix]

I hope it isn't transient, and an intentional fix (to some code or the build environment) was applied.

I don't know. I think @jef-n knows for sure.

I didn't see any commits on the repo since you mentioned that it was fixed

[hellik]

tested with OSGeo4W

GRASS version: 8.5.0dev                                                         
Code revision: 0b0cffce0                                                        
Build date: 2024-06-16                                                          
Build platform: x86_64-w64-mingw32                                              
GDAL: 3.9.0                                                                     
PROJ: 9.4.0                                                                     
GEOS: 3.12.2                                                                    
SQLite: 3.45.1                                                                  
Python: 3.12.4                                                                  
wxPython: 4.2.1                                                                 
Platform: Windows-11-10.0.22631-SP0 (OSGeo4W)     

GUI starts here. closing ticket?