[GRASS-dev] [GRASS GIS] #1866: broken SQLite driver in winGRASS 7

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------
In winGRASS 7 also SQLite driver is not working (see #1844 from DBF
driver). NC (basic) dataset.

{{{
db.describe census
}}}

doesn't report any error, it just hangs. Adding some extra debug messages,
I found the line when it stops. It's
source:grass/trunk/lib/db/dbmi_base/xdrcolumn.c#L56. First three columns
are retrieved (cat, OBJRCTID, AREA). It stops on fourth column and waiting
for response.

Any idea where could be a problem?

This bugs affects only GRASS 7, SQLite driver in GRASS 6 seems to work.

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

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by martinl):

Update: string for name of fourth column has invalid size (should be for
this column - PERIMETER - 10). Seems like buffer overflow or so(?)

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

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by martinl):

Wild guess: could be related to invalid call of `free()` (instead of
`dbfree()`). Any tips how to determine such invalid usage?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1866#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by mmetz):

Replying to [comment:2 martinl]:
> Wild guess: could be related to invalid call of `free()` (instead of
`dbfree()`). Any tips how to determine such invalid usage?

I have changed the default error reporting setting for db drivers in
r54828. Maybe something useful is now printed. Please test.

Markus M

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1866#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by martinl):

Replying to [comment:3 mmetz]:

> I have changed the default error reporting setting for db drivers in
r54828. Maybe something useful is now printed. Please test.

thanks, anyway unfortunately nothing is printed.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1866#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by martinl):

To be more specific, when adding some extra debug messages

{{{
Index: lib/db/dbmi_base/xdrcolumn.c

--- dbmi_base/xdrcolumn.c (revision 54829)
+++ dbmi_base/xdrcolumn.c (working copy)
@@ -53,6 +53,8 @@
  int db__recv_column_definition(dbColumn * column)
  {
      DB_RECV_STRING(&column->columnName);
+ G_debug(0, "col: %s (%d)", db_get_string(&column->columnName),
+ db_sizeof_string(&column->columnName));
      DB_RECV_STRING(&column->description);
      DB_RECV_INT(&column->sqlDataType);
      DB_RECV_INT(&column->hostDataType);
}}}

I am getting

{{{
db.describe census
D0/0: col: cat (4)
D0/0: col: OBJECTID (9)
D0/0: col: AREA (5)
D0/0: col: (2573)
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1866#comment:5&gt;
GRASS GIS <http://grass.osgeo.org>

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by mmetz):

Replying to [comment:4 martinl]:
> Replying to [comment:3 mmetz]:
>
> > I have changed the default error reporting setting for db drivers in
r54828. Maybe something useful is now printed. Please test.
>
> thanks, anyway unfortunately nothing is printed.

I get exactly the same behaviour with the dbf driver: nothing happens, no
error message and the driver hangs.

Markus M

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1866#comment:6&gt;
GRASS GIS <http://grass.osgeo.org>

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by martinl):

Replying to [comment:6 mmetz]:

> I get exactly the same behaviour with the dbf driver: nothing happens,
no error message and the driver hangs.

strangely, in GRASS 6 both DBF and SQLite seems to work.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1866#comment:7&gt;
GRASS GIS <http://grass.osgeo.org>

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by mmetz):

Replying to [comment:7 martinl]:
> Replying to [comment:6 mmetz]:
>
> > I get exactly the same behaviour with the dbf driver: nothing happens,
no error message and the driver hangs.
>
> strangely, in GRASS 6 both DBF and SQLite seems to work.

Strangely, in GRASS 7 both DBF and SQLite driver seem to work. What is
broken is the pipe for sending data back and forth between the module and
the driver.

Markus M

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1866#comment:8&gt;
GRASS GIS <http://grass.osgeo.org>

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by mmetz):

Replying to [comment:8 mmetz]:
> Replying to [comment:7 martinl]:
> > Replying to [comment:6 mmetz]:
> >
> > > I get exactly the same behaviour with the dbf driver: nothing
happens, no error message and the driver hangs.
> >
> > strangely, in GRASS 6 both DBF and SQLite seems to work.
>
> Strangely, in GRASS 7 both DBF and SQLite driver seem to work. What is
broken is the pipe for sending data back and forth between the module and
the driver.

I added some more debug info and get for `db.describe boundary_county`

{{{
D0/0: send column name: cat
D0/0: D0/0: receive string of len: 4
D0/0: string alloc: 0
D0/0: string received: cat
D0/0: column name: cat
D0/0: receive string of len: 1
D0/0: string alloc: 0
D0/0: string received:
send column name: AREA
D0/0: D0/0: receive string of len: 5
D0/0: string alloc: 0
D0/0: string received: AREA
D0/0: column name: AREA
D0/0: receive string of len: 1
D0/0: string alloc: 0
D0/0: string received:
send column name: PERIMETER
D0/0: D0/0: receive string of len: 2573
D0/0: string alloc: 0
send column name: FIPS
D0/0: send column name: NAME
D0/0: send column name: NAME_LOCAS
D0/0: send column name: DOT_DISTRI
D0/0: send column name: DOT_DIVISI
D0/0: send column name: DOT_COUNTY
D0/0: send column name: COUNTY_100
D0/0: send column name: DOT_GROUP_
D0/0: send column name: ACRES
D0/0: send column name: ABBR_5CHAR
D0/0: send column name: ABBR_4CHAR
D0/0: send column name: ABBR_2CHAR
D0/0: send column name: Z_MEAN
D0/0: send column name: Z_MIN
D0/0: send column name: Z_MAX
D0/0: send column name: Z_ZONE
D0/0: send column name: CO_CENSUS
D0/0: send column name: DIV_CONTAC
D0/0: send column name: DIST_CONTA
D0/0: send column name: CO_WIKIPED
D0/0: send column name: Shape_Leng
D0/0: send column name: Shape_Area
}}}

Apparently the receiving end of the pipe [0] is broken. Anybody has any
idea how this could happen? There are no obvious differences in the code
base between 6.4. and 7.0.

Markus M

[0]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/db/dbmi_client/start.c#L130

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1866#comment:9&gt;
GRASS GIS <http://grass.osgeo.org>

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by martinl):

Replying to [comment:9 mmetz]:

> Apparently the receiving end of the pipe [0] is broken. Anybody has any
idea how this could happen? There are no obvious differences in the code
base between 6.4. and 7.0.

Any idea here? This is really '''critical''' issue. Currently winGRASS 7
is completely broken when working with vector data. Two main DB drivers
(SQLite, DBF) are broken.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1866#comment:10&gt;
GRASS GIS <http://grass.osgeo.org>

#1866: broken SQLite driver in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by cmbarton):

This seems to be working fine on the Mac for R55039. I just did
db.describe for forestations in the nc_spm_08 demo set for data in sqlite.
No problem.

Michael

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

#1866: broken db driver communication in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by mmetz):

Replying to [comment:11 cmbarton]:
> This seems to be working fine on the Mac for R55039. I just did
db.describe for forestations in the nc_spm_08 demo set for data in sqlite.
No problem.

The drivers are working just fine. Someone is not listening properly, i.e.
the dblib as used by modules, because the drivers are sending correct
information, but the dblib receives bargage. There are some parts in the
code, in the db lib, in gislib for spawning and in the wxGUI that have
switches for Windows. But the relevant code in the db drivers, the db lib
and gislib is identical between 6.4, 6.5 and 7. The only differences I
could find between trunk and devbr6/relbr64 are in the GRASS startup
script and in the wxGUI. Is it possible that the wxGUI or the startup
script are highjacking file descriptors of the pipes?

Markus M

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

#1866: broken db driver communication in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by martinl):

Replying to [comment:11 cmbarton]:
> This seems to be working fine on the Mac for R55039. I just did
db.describe for forestations in the nc_spm_08 demo set for data in sqlite.
No problem.

Thanks for testing. It's working also on GNU/Linux too, it's problem only
on Windows.

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

#1866: broken db driver communication in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by mmetz):

Replying to [comment:12 mmetz]:
> Replying to [comment:11 cmbarton]:
> > This seems to be working fine on the Mac for R55039. I just did
db.describe for forestations in the nc_spm_08 demo set for data in sqlite.
No problem.
>
> The drivers are working just fine. Someone is not listening properly,
i.e. the dblib as used by modules, because the drivers are sending correct
information, but the dblib receives bargage. There are some parts in the
code, in the db lib, in gislib for spawning and in the wxGUI that have
switches for Windows. But the relevant code in the db drivers, the db lib
and gislib is identical between 6.4, 6.5 and 7. The only differences I
could find between trunk and devbr6/relbr64 are in the GRASS startup
script and in the wxGUI. Is it possible that the wxGUI or the startup
script are highjacking file descriptors of the pipes?

The db driver communication was broken with r53257, September 2012. For
some unknown reason, wingrass needs to be linked against -lxdr, even
though all references to the xdr lib should have been eliminated. Fixed in
r55332, but this ticket should not be closed until the ultimate reason is
known.

Markus M

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

#1866: broken db driver communication in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by glynn):

Replying to [comment:14 mmetz]:
> Fixed in r55332
r55332 doesn't fix anything, but instead breaks linking (because libxdr
typically won't exist). Reverted in r55335.

In what way does the DBMI client lib receive "garbage"? Is the data simply
corrupted, or does it bear absolutely no relation to what the driver
sends?

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

#1866: broken db driver communication in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by martinl):

seems to be related to #1796, #1844, and probably more tickets. It's very
good news, that we know at least what is source of the problems (thanks
MarkusM for discovering that).

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

#1866: broken db driver communication in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by mmetz):

Replying to [comment:15 glynn]:
> Replying to [comment:14 mmetz]:
> > Fixed in r55332
> r55332 doesn't fix anything, but instead breaks linking (because libxdr
typically won't exist).

libxdr exists in osgeo4w [0]. I don't know why r55332 works, but it works.
IOW, r53256 works, r53257 does not work.

> Reverted in r55335.

I am inclined to revert r55335 until a proper solution is found.
>
> In what way does the DBMI client lib receive "garbage"? Is the data
simply corrupted, or does it bear absolutely no relation to what the
driver sends?

The communication pipe first sends the size of the string, then the string
itself [1]. After the first few transmissions, the size of the string as
sent by the driver is correct, but the size of the string as received by
the dblib is too large. That means the driver continues sending correct
data with `db__send_string()` while `db__recv_string()` still waits for a
very large string to appear, which never appears. As a result, nothing
happens and the modules using dblib hang.

[0] http://download.osgeo.org/osgeo4w/release/libxdr/libxdr/
[1]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/db/dbmi_base/xdrstring.c#L86

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

#1866: broken db driver communication in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by martinl):

Replying to [comment:17 mmetz]:
> > Reverted in r55335.
>
> I am inclined to revert r55335 until a proper solution is found.

agreed, note that since sep 2012 db drivers like dbf and sqlite are broken
on Windows. In other words, winGRASS7 completely unusable when working
with attribute tables. This is really critical issue.

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

#1866: broken db driver communication in winGRASS 7
------------------------------+---------------------------------------------
Reporter: martinl | Owner: grass-dev@…
     Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Database | Version: unspecified
Keywords: sqlite, wingrass | Platform: MSWindows 2K
      Cpu: Unspecified |
------------------------------+---------------------------------------------

Comment(by mmetz):

Replying to [comment:17 mmetz]:
> Replying to [comment:15 glynn]:
> > Replying to [comment:14 mmetz]:
> > > Fixed in r55332
> > r55332 doesn't fix anything, but instead breaks linking (because
libxdr typically won't exist).
>
> libxdr exists in osgeo4w [0]. I don't know why r55332 works, but it
works. IOW, r53256 works, r53257 does not work.
>
> > Reverted in r55335.
>
> I am inclined to revert r55335 until a proper solution is found.
> >
> > In what way does the DBMI client lib receive "garbage"? Is the data
simply corrupted, or does it bear absolutely no relation to what the
driver sends?
>
> The communication pipe first sends the size of the string, then the
string itself [1]. After the first few transmissions, the size of the
string as sent by the driver is correct, but the size of the string as
received by the dblib is too large. That means the driver continues
sending correct data with `db__send_string()` while `db__recv_string()`
still waits for a very large string to appear, which never appears. As a
result, nothing happens and the modules using dblib hang.

> [0] http://download.osgeo.org/osgeo4w/release/libxdr/libxdr/
> [1]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/db/dbmi_base/xdrstring.c#L86

Some more information:

Linking only dbmi_base and/or dbmi_client against libxdr does not help.
Linking only gislib against xdrlib does not help either. The change in
r55332 is the only way I found to get the db drivers working.

Linking against xdr has been removed in order to get GRASS compiled on
Android, which is not a supported platform. I prefer to have GRASS working
on the supported platforms, even if it is a hack, and am thus restoring
r55332 until the underlying cause of the bug is found and fixed.

Testing in the NC dataset with

{{{
v.info -c map=boundary_county
}}}

I get with additional debug info in wingrass7 without libxdr

{{{
Displaying column types/names for database
D0/0: send string of len: 38
D0/0: send string of len: 1
D0/0: receive string of len: 38
D0/0: string received: C:\GRASSdata\nc_spm
D0/0: receive string of len: 1
D0/0: string received:
D0/0: send string of len: 16
D0/0: receive string of len: 16
D0/0: string received: boundary_county
D0/0: send column name: cat
D0/0: send string of len: 4
D0/0: D0/0: receive string of len: 4
}}}
The pipe is now broken because it continues with
{{{
D0/0: send string of len: 1
D0/0: send column name: AREA
D0/0: send string of len: 5
D0/0: send string of len: 1
D0/0: send column name: PERIMETER
D0/0: send string of len: 10
D0/0: send string of len: 1
D0/0: string received: cat
D0/0: column name: cat
D0/0: receive string of len: 1
D0/0: string received:
}}}
Here garbage is received: the string length received is 1280 instead of 5:
{{{
D0/0: receive string of len: 1280
send column name: FIPS
D0/0: send string of len: 5
D0/0: send string of len: 1
D0/0: send column name: NAME
D0/0: send string of len: 5
D0/0: send string of len: 1
D0/0: send column name: NAME_LOCAS
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: DOT_DISTRI
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: DOT_DIVISI
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: DOT_COUNTY
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: COUNTY_100
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: DOT_GROUP_
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: ACRES
D0/0: send string of len: 6
D0/0: send string of len: 1
D0/0: send column name: ABBR_5CHAR
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: ABBR_4CHAR
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: ABBR_2CHAR
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: Z_MEAN
D0/0: send string of len: 7
D0/0: send string of len: 1
D0/0: send column name: Z_MIN
D0/0: send string of len: 6
D0/0: send string of len: 1
D0/0: send column name: Z_MAX
D0/0: send string of len: 6
D0/0: send string of len: 1
D0/0: send column name: Z_ZONE
D0/0: send string of len: 7
D0/0: send string of len: 1
D0/0: send column name: CO_CENSUS
D0/0: send string of len: 10
D0/0: send string of len: 1
D0/0: send column name: DIV_CONTAC
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: DIST_CONTA
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: CO_WIKIPED
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: Shape_Leng
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send column name: Shape_Area
D0/0: send string of len: 11
D0/0: send string of len: 1
D0/0: send string of len: 16
D0/0: send string of len: 1
}}}

Linking against xdrlib I get

{{{
Displaying column types/names for data
D0/0: send string of len: 38
D0/0: send string of len: 1
D0/0: receive string of len: 38
D0/0: string received: C:\GRASSdata\nc
D0/0: receive string of len: 1
D0/0: string received:
D0/0: send string of len: 16
D0/0: receive string of len: 16
D0/0: string received: boundary_county
D0/0: send column name: cat
D0/0: send string of len: 4
D0/0: D0/0: receive string of len: 4
D0/0: string received: cat
D0/0: column name: cat
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: AREA
D0/0: send string of len: 5
D0/0: D0/0: receive string of len: 5
D0/0: string received: AREA
D0/0: column name: AREA
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: PERIMETER
D0/0: send string of len: 10
D0/0: D0/0: receive string of len: 10
D0/0: string received: PERIMETER
D0/0: column name: PERIMETER
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: FIPS
D0/0: send string of len: 5
D0/0: D0/0: receive string of len: 5
D0/0: string received: FIPS
D0/0: column name: FIPS
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: NAME
D0/0: send string of len: 5
D0/0: D0/0: receive string of len: 5
D0/0: string received: NAME
D0/0: column name: NAME
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: NAME_LOCAS
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: NAME_LOCAS
D0/0: column name: NAME_LOCAS
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: DOT_DISTRI
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: DOT_DISTRI
D0/0: column name: DOT_DISTRI
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: DOT_DIVISI
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: DOT_DIVISI
D0/0: column name: DOT_DIVISI
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: DOT_COUNTY
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: DOT_COUNTY
D0/0: column name: DOT_COUNTY
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: COUNTY_100
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: COUNTY_100
D0/0: column name: COUNTY_100
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: DOT_GROUP_
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: DOT_GROUP_
D0/0: column name: DOT_GROUP_
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: ACRES
D0/0: send string of len: 6
D0/0: D0/0: receive string of len: 6
D0/0: string received: ACRES
D0/0: column name: ACRES
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: ABBR_5CHAR
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: ABBR_5CHAR
D0/0: column name: ABBR_5CHAR
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: ABBR_4CHAR
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: ABBR_4CHAR
D0/0: column name: ABBR_4CHAR
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: ABBR_2CHAR
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: ABBR_2CHAR
D0/0: column name: ABBR_2CHAR
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: Z_MEAN
D0/0: send string of len: 7
D0/0: D0/0: receive string of len: 7
D0/0: string received: Z_MEAN
D0/0: column name: Z_MEAN
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: Z_MIN
D0/0: send string of len: 6
D0/0: D0/0: receive string of len: 6
D0/0: string received: Z_MIN
D0/0: column name: Z_MIN
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: Z_MAX
D0/0: send string of len: 6
D0/0: D0/0: receive string of len: 6
D0/0: string received: Z_MAX
D0/0: column name: Z_MAX
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: Z_ZONE
D0/0: send string of len: 7
D0/0: D0/0: receive string of len: 7
D0/0: string received: Z_ZONE
D0/0: column name: Z_ZONE
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: CO_CENSUS
D0/0: send string of len: 10
D0/0: D0/0: receive string of len: 10
D0/0: string received: CO_CENSUS
D0/0: column name: CO_CENSUS
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: DIV_CONTAC
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: DIV_CONTAC
D0/0: column name: DIV_CONTAC
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: DIST_CONTA
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: DIST_CONTA
D0/0: column name: DIST_CONTA
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: CO_WIKIPED
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: CO_WIKIPED
D0/0: column name: CO_WIKIPED
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: Shape_Leng
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: Shape_Leng
D0/0: column name: Shape_Leng
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send column name: Shape_Area
D0/0: send string of len: 11
D0/0: D0/0: receive string of len: 11
D0/0: string received: Shape_Area
D0/0: column name: Shape_Area
send string of len: 1
D0/0: D0/0: receive string of len: 1
D0/0: string received:
send string of len: 16
D0/0: D0/0: receive string of len: 16
D0/0: string received: boundary_county
send string of len: 1
D0/0: receive string of len: 1
D0/0: string received:
INTEGER|cat
DOUBLE PRECISION|AREA
DOUBLE PRECISION|PERIMETER
DOUBLE PRECISION|FIPS
CHARACTER VARYING|NAME
CHARACTER VARYING|NAME_LOCAS
INTEGER|DOT_DISTRI
INTEGER|DOT_DIVISI
INTEGER|DOT_COUNTY
INTEGER|COUNTY_100
CHARACTER VARYING|DOT_GROUP_
DOUBLE PRECISION|ACRES
CHARACTER VARYING|ABBR_5CHAR
CHARACTER VARYING|ABBR_4CHAR
CHARACTER VARYING|ABBR_2CHAR
DOUBLE PRECISION|Z_MEAN
DOUBLE PRECISION|Z_MIN
DOUBLE PRECISION|Z_MAX
DOUBLE PRECISION|Z_ZONE
CHARACTER VARYING|CO_CENSUS
CHARACTER VARYING|DIV_CONTAC
CHARACTER VARYING|DIST_CONTA
CHARACTER VARYING|CO_WIKIPED
DOUBLE PRECISION|Shape_Leng
DOUBLE PRECISION|Shape_Area
GRASS 7.0.svn>
}}}

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