#1020: Display of vector maps fails
----------------------+-----------------------------------------------------
Reporter: MilenaN | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Keywords: wingrass | Platform: MSWindows 7
Cpu: x86-64 |
----------------------+-----------------------------------------------------
GRASS freezes when trying to open a vector map. Both Apply and OK buttons
has been tested.
Raster maps can be opened with no problem.
I also noticed, that enabling DEBUG will make WxGUI to hang (Not
responding). MilenaN - can You run "g.gisenv set='DEBUG=0'" in GUI CMD
prompt or CMD and then try to display vector map?
Replying to [ticket:1020 MilenaN]:
> GRASS freezes when trying to open a vector map. Both Apply and OK
buttons has been tested.
> Raster maps can be opened with no problem.
I have similar problem on MS Windows 2008.
Running GRASS locally from MSYS works, i.e. I can display a vector map.
> When running manually from MSYS
{{{
GRASS 6.4> db.describe -c --q table=archsites driver=dbf \
database="C:\Users\landa\grass data/spearfish60/PERMANENT/dbf/"
Bad file descriptor: Files
}}}
... perhaps stating the obvious, but it looks like we missed quoting a
path name variable and the $GISBASE/driver/db/dbf program is being sent as
"C:\Program" and then "Files\GRASS64\..." ??
what do the previous debug messages say with DEBUG=5?
Replying to [comment:5 hamish]:
> > When running manually from MSYS
{{{
> GRASS 6.4> db.describe -c --q table=archsites driver=dbf \
> database="C:\Users\landa\grass data/spearfish60/PERMANENT/dbf/"
> Bad file descriptor: Files
}}}
>
> ... perhaps stating the obvious, but it looks like we missed quoting a
path name variable and the $GISBASE/driver/db/dbf program is being sent as
"C:\Program" and then "Files\GRASS64\..." ??
>
> what do the previous debug messages say with DEBUG=5?
Doesn't seems to be that problem (note that $GISBASE contains a space)
is "C:\Program Files (x86)" common for 64bit Windows7 or a local install
choice? Including $arch there is something new to me. Is that $arch seen
with Vista 64bit too?
> seems to be problem with _spawnl
> grass/branches/releasebranch_6_4/lib/db/dbmi_client/start.c@41132#L221
apparently so.
that is the only place in the 6.4 code that uses _spawnl(), although
lib/gis/system.c uses, and comments in g.parser speak of _spawnlp().
one obvious thing is that in the non-osgeo4w install the `startup` string
does is missing an executable name (which must end in .exe for _spawnl()
too), it is just the dir. (but where is the closing "]" on that string
too?)
Yep. _spawnl() simply concatenates its arguments, with spaces between
them; it doesn't perform any quoting.
An example of "correct" quoting can be found in escape_arg() in
lib/gis/spawn.c. "correct" in quotes because it's up to the C runtime as
to how to parse the command line into individual arguments; the
escape_arg() function matches the MSVC behaviour, and is the same
algorithm as used by e.g. Python's subprocess module (see list2cmdline()
in subprocess.py).
Replying to [comment:9 glynn]:
> > seems to be problem with _spawnl
>
> Yep. _spawnl() simply concatenates its arguments, with spaces between
them; it doesn't perform any quoting.
>
> An example of "correct" quoting can be found in escape_arg() in
lib/gis/spawn.c. "correct" in quotes because it's up to the C runtime as
to how to parse the command line into individual arguments; the
escape_arg() function matches the MSVC behaviour, and is the same
algorithm as used by e.g. Python's subprocess module (see list2cmdline()
in subprocess.py).
>
> MSDN reference: http://msdn.microsoft.com/en-us/library/17w5ykft.aspx
> Couldn't we use simply G_spawn() or G_spawn_ex()?
Assuming that the current G_spawn_ex() works reliably on Windows, it can
be used. Earlier versions didn't support redirection of stdin/stdout on
Windows.
The new version made it into RC6, so I'm assuming that it's basically
okay.
Glynn:
> The new version made it into RC6, so I'm assuming that it's
> basically okay.
..although nothing there actually calls it, the 6.4 lib/gis/spawn.c is
identical to the version which is used by g.gui in 6.5, so presumably it's
pretty well tested by now.
Replying to [comment:13 glynn]:
> Replying to [comment:11 martinl]:
>
> > Couldn't we use simply G_spawn() or G_spawn_ex()?
>
> Assuming that the current G_spawn_ex() works reliably on Windows, it can
be used. Earlier versions didn't support redirection of stdin/stdout on
Windows.
>
> The new version made it into RC6, so I'm assuming that it's basically
okay.
Most of the bottom half of db_start_driver() (the part that's split into
distinct !Windows/Unix versions) should be replaced with a call to
G_spawn_ex().
Replying to [comment:16 glynn]:
> Most of the bottom half of db_start_driver() (the part that's split into
distinct !Windows/Unix versions) should be replaced with a call to
G_spawn_ex().
>
> Try r42651.
Thanks! Seems to work, backported in r42654 to devbr6 (available for
testing in the next daily build on http://josef.fsv.cvut.cz/wingrass).
Martin
> Seems to also work in devbr6. When displaying archsites from spearfish60
I am just getting some warnings
>
{{{
G_spawn: unable to redirect descriptor 4
G_spawn: unable to redirect descriptor 5
}}}
>
> Any idea how it could be fixed. Thanks.
Replying to [comment:19 glynn]:
> Replying to [comment:18 martinl]:
>
> > Seems to also work in devbr6. When displaying archsites from
spearfish60 I am just getting some warnings
> Backport r40905.
Done in r42667 (devbr6) and r42668 (relbr64). Martin