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

[GRASS GIS]

#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:17 mmetz]:

 > > Reverted in r55335.
 >
 > I am inclined to revert r55335 until a proper solution is found.

 Reinstating the hack makes it less likely that a proper solution will be
 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 doesn't really help. What would help would be the actual bytes. But I
 can hazard a guess based upon comment:19:

 > Here garbage is received: the string length received is 1280 instead of
 5:

 5 = 0x00000005 = "\x05\x00\x00\x00"

 1280 = 0x00000500 = "\x00\x05\x00\x00"

 It appears that an extra character has been inserted somewhere in the
 stream. The usual suspect is LF->CRLF conversion. That is supposed to be
 prevented by linking everything against fmode.o, but it's possible that
 isn't happening for some reason, or something else is overriding it. Also,
 `G_gisinit()` and `G__gisinit()` explicitly set "_fmode = O_BINARY", but
 those functions don't appear to be called by DBMI drivers (although they
 typically call other libgis functions, e.g. `G__setenv()`).

 But rather than guess, it would be better to instrument `db__send()` and
 `db__recv()` to dump the data as hex.

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