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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
