[GRASS-dev] [GRASS GIS] #3833: pygrass.gis.region.Region + WIND_OVERRIDE + non-existing path kills the process

#3833: pygrass.gis.region.Region + WIND_OVERRIDE + non-existing path kills the
process
-------------------------+-------------------------
Reporter: pmav99 | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone:
Component: PyGRASS | Version: unspecified
Keywords: | CPU: Unspecified
Platform: Unspecified |
-------------------------+-------------------------
If you define {{{WIND_OVERRIDE}}} to a non existing path, then,
instantiating a {{{Region}}} object results in a fatal error which kills
the current process. This is a problem if you are e.g. in an interactive
ipython session. Example:

{{{
import os
from grass.pygrass.gis.region import Region

os.environ["WIND_OVERRIDE"] = 'aaaa'
r = Region()

# results in a dead python process with the following message:
# ERROR: Unable to open element file <windows> for <aaaa@PERMANENT>
}}}

The problem is that the {{{Region.read()}}} method calls
{{{G_get_window}}} which calls {{{G_get_element_window}}}, which calls
{{{G_fatal_window}}} if the file does not exist.

Adding a check for {{{WIND_OVERRIDE}}} and the existence of the file in
{{{Region.read()}}} would solve the issue for most practical purposes, but
would be subject to a race condition. Not sure what to suggest.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3833&gt;
GRASS GIS <https://grass.osgeo.org>

#3833: pygrass.gis.region.Region + WIND_OVERRIDE + non-existing path kills the
process
--------------------------+-------------------------
  Reporter: pmav99 | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone:
Component: PyGRASS | Version: unspecified
Resolution: | Keywords:
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by pmav99):

OK, the problem seems to be that the generated gis.py (i.e.
{{{lib/python/ctypes/OBJ.x86_64-pc-linux-gnu/gis.py]}}}), doesn't define
{{{errcheck}}} for some of the functions, including {{{G_get_window}}} and
{{{G_get_element_window}}}. Can anyone provide a hint, why these functions
don't have {{{errcheck}}} defined while others do?

Some relevant links:

- [https://stackoverflow.com/questions/24349806/catch-exception-in-ctypes-
based-on-c-exit-code SO question]
- The same problem was solved
[https://github.com/DECODEproject/zenroom/issues/47#issuecomment-446173032
here] using
[https://docs.python.org/3/library/ctypes.html#ctypes._FuncPtr.errcheck
ctypes.errcheck]
- [https://stackoverflow.com/questions/50669907/how-to-use-ctypes-errcheck
SO example using errcheck]

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3833#comment:1&gt;
GRASS GIS <https://grass.osgeo.org>