Display of vector maps fails

[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.

[marisn]

Works fine on Vista WinGRASS-6.4.SVN-r41749-1.

Could be something like Vista UAC related issues?

[marisn]

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?

[martinl]

Replying to 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.

landa@GEO1 /osgeo4w/usr/src/grass64_release
$ ./bin.i686-pc-mingw32/grass64 -wx

Running installed version, GRASS freezes when displaying a vector map. Reason is db.describe command which is launched on the background.

GUI D1/1: gcmd.Command(): db.describe -c --q table=archsites driver=dbf database=C:\Users\landa\grass data/spearfish60/PERMANENT/dbf/
UPOZORNÌNÍ: Nelze spustit pøíkaz

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

The same command works when running the command from OSGeo MSYS

db.describe -c --q table=archsites driver=dbf database="C:\Users\landa\grass data/spearfish60/PERMANENT/dbf/"
ncols: 2
nrows: 25
Column 1: cat:INTEGER:11
Column 2: str1:CHARACTER:30

Any pointers?

[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?

Hamish

[martinl]

Replying to 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)

GRASS 6.4> db.describe -c --q table=archsites driver=dbf database="C:\Users\landa\grass data/spearfish60/PERMANENT/dbf/"
D2/5: dbDbmscap(): opendir [c:\osgeo4w\usr\src\grass64 release\dist.i686-pc-mingw32\driver\db\]
D2/5: dbDbmscap(): opendir [c:\osgeo4w\usr\src\grass64 release\dist.i686-pc-mingw32\driver\db\]
D2/5: dbmi_client/start startup: [c:\osgeo4w\usr\src\grass64 release\dist.i686-pc-mingw32\driver\db\dbf.exe]
D2/5: DBF: db__driver_open_database() name = 'C:\Users\landa\grass data/spearfish60/PERMANENT/dbf/'
D2/5: db.name = C:\Users\landa\grass data/spearfish60/PERMANENT/dbf/
...

But

GRASS 6.4> db.describe -c --q table=archsites driver=dbf database="C:\Users\land
D2/5: dbDbmscap(): opendir [c:\Program Files (x86)\GRASS-64-SVN\driver\db\]
D2/5: dbDbmscap(): opendir [c:\Program Files (x86)\GRASS-64-SVN\driver\db\]
D2/5: dbmi_client/start startup: [c:\Program Files (x86)\GRASS-64-SVN\driver\db\
Bad file descriptor: Files

[martinl]

Replying to martinl:

But

> GRASS 6.4> db.describe -c --q table=archsites driver=dbf database="C:\Users\land
> D2/5: dbDbmscap(): opendir [c:\Program Files (x86)\GRASS-64-SVN\driver\db\]
> D2/5: dbDbmscap(): opendir [c:\Program Files (x86)\GRASS-64-SVN\driver\db\]
> D2/5: dbmi_client/start startup: [c:\Program Files (x86)\GRASS-64-SVN\driver\db\
> Bad file descriptor: Files

seems to be problem with _spawnl grass/branches/releasebranch_6_4/lib/db/dbmi_client/start.c@41132#L221​

[hamish]

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?)

Hamish

[glynn]

Replying to martinl:

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

[martinl]

Replying to hamish:

is "C:\Program Files (x86)" common for 64bit Windows7 or a local install choice? Including

yes.

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?)

sorry, the message has been just truncated...

[martinl]

Replying to 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()?

[glynn]

Replying to 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.

[hamish]

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.

[martinl]

Replying to glynn:

Replying to 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.

my wild guess

     G_debug(2, "dbmi_client/start startup: [%s]", startup);
-    pid = _spawnl(_P_NOWAIT, startup, startup, NULL);
+    pid = G_spawn_ex(startup, startup, NULL);

fails. Any hits how to fix this blocker issue.

[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.

[martinl]

Replying to 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

[martinl]

Replying to martinl:

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.

[glynn]

Replying to martinl:

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.

Backport r40905.

[martinl]

Replying to glynn:

Replying to 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

[crazyb0b]

Replying to martinl:

Replying to glynn:

Replying to 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

I'm getting this error on x64_64 Linux (Arch Linux) with a newly built r42701 from trunk. Is there any resolution?

[hamish]

Replying to crazyb0b:

I'm getting this error on x64_64 Linux (Arch Linux) with a newly built r42701 from trunk. Is there any resolution?

what's the exact error message?

[martinl]

Replying to crazyb0b:

Done in r42667 (devbr6) and r42668 (relbr64). Martin

I'm getting this error on x64_64 Linux (Arch Linux) with a newly built r42701 from trunk. Is there any resolution?

Please provide more precise description... Can you reproduce this behaviour also with GRASS 6.4?

Martin

[crazyb0b]

Replying to martinl:

Please provide more precise description...

Martin

Most of the time the GUI just freezes up with the selection box in the clicked position. Other times I receive this message:

The program 'python' received an X Window System error.

This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'.

(Details: serial 2659954 error_code 1 request_code 121 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously;

that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)

Can you reproduce this behaviour also with GRASS 6.4?

I've been using the TCLTK GUI in 6.4 and that seems to work just fine. I'll try later with the wxPython GUI and see if the same issue occurs.

[glynn]

Replying to crazyb0b:

Most of the time the GUI just freezes up with the selection box in the clicked position. Other times I receive this message:

The program 'python' received an X Window System error.

This probably reflects a bug in the program. The error was 'BadRequest (invalid request code or no such operation)'.

(Details: serial 2659954 error_code 1 request_code 121 minor_code 0)

This is an entirely unrelated issue. Please open a new defect for it.

[martinl]

Replying to glynn:

This is an entirely unrelated issue. Please open a new defect for it.

Right, it's seems to me that we can close this ticket.

[hellik]

Replying to martinl:

Replying to glynn:

This is an entirely unrelated issue. Please open a new defect for it.

Right, it's seems to me that we can close this ticket.

see also #1121.

I've tested this with WinGRASS-6.4.SVN-r42912-1-Setup.exe on WinVista32. I can't reproduce this.

Helmut

[martinl]

Please reopen the ticket if needed.