[GRASS-dev] native WinGRASS and attribute data deadlock, next try

[Glynn Clements]

Moritz Lennert wrote:

> Here's a new try at getting useful log output and actually I do get
> strange results.
> 
> Running 'v.out.ogr points type=point dsn=c:\test' I still don't get any
> message (except for once where '1%' appeared). I can see dbf.exe in the
> windows task manager, but no I/O activity whatsoever. However, when I open
> the resulting log file in oocalc, it is 'read-only' which makes me suppose
> that the file is not closed yet. It seems as if the process hangs in the
> middle of a function, which might explain the uncomplete lines we've
> already seen towards the end of the log file. I always have to Ctrl-C to
> get out of the command and to get write access to the log files.
> 
> I have no idea how to identify which is the driver and which the client -

The communication starts with the driver writing a success/failure
code. So, in your log.csv file, the left-hand columns are the client
and the right-hand columns are the driver.

> and also no idea if this makes any difference - so I just called them
> side1 and side2 in the code. In the attached log file I already put them
> next to each other.
> 
> Some of the log files do not show anything interesting (AFAICS), but in
> some one of the processes (the one on the sending side in stream 1)
> creates much more output than the other, and just before the other (i.e.
> the receiving side) stops, the values begin to differ with the receiving
> side truncating a few zeros of the value (see lines 23ff in log file).

Yep. Converting them to formatted text, the server side has:

20	putbytes	STREAM1		3	63 61 74 
21	putbytes	STREAM1		1	00
22	putlong		STREAM1		4	00 00 00 01
23	putlong		STREAM1		4	00 00 00 00
24	putlong		STREAM1		4	00 00 00 03
25	putlong		STREAM1		4	00 00 00 02

while the client has:

20	getbytes	STREAM1		3	63 61 74 
21	getbytes	STREAM1		1	00
22	getlong		STREAM1		4	00 00 01 00
23	getlong		STREAM1		4	00 00 00 00
24	getlong		STREAM1		4	00 00 03 00
25	getlong		STREAM1		4	00 00 02 00

At line 22, a zero goes missing from the stream. From there on, all
bets are off.

It doesn't stop there; at line 27 or 28, another zero goes missing.

My next suggestion is to re-write xdr_stdio to use read() and write()
instead of fread() and fwrite(), e.g.:

-	if (fread((caddr_t)lp, sizeof(long), 1, (FILE *)xdrs->x_private) != 1)
+	if (read(fileno((FILE *)xdrs->x_private), (caddr_t)lp, sizeof(long)) != sizeof(long))

That should tell us whether the problem is with the MSVCRT stdio
implementation or a lower level. If it's stdio, we can replace that
with read/write. If it still manifests itself with those functions, we
may need to use ReadFile/WriteFile instead. Or a named pipe.

-- 
Glynn Clements <glynn at gclements.plus.com>