Markus Neteler wrote:
> >> > You could try re-compiling the DBMI libraries with -DUSE_BUFFERED_IO
> >> > to see if that helps at all.
> >>
> >> It makes things worse: I have killed the job after 6minutes... (DBF).
> >
> > That implies there's a deadlock, i.e. one side is waiting for data
> > which is sitting in the other side's buffer.
> >
> > I'm not sure how that occurs; reading from a stream should flush any
> > output streams. It would be useful if you could debug this to see
> > where it's blocking.
>
> I am not sure how to debug such a case, I simply used gdb, waited,
> then CTRL-C and bt:
In general, you need two terminals, to show both sides, e.g.:
1.
$ pidof v.what.rast
$ gdb $GISBASE/bin/v.what.rast
> attach <pid of v.what.rast process>
> bt
2.
$ pidof dbf
$ gdb $GISBASE/driver/db/dbf
> attach <pid of dbf process>
> bt
You may need to set up PATH and LD_LIBRARY_PATH manually so that it
finds the correct binaries.
However, I don't think that it's going to tell me much in this case;
the driver is almost certainly at lib/db/dbmi_driver/driver.c:140 (the
db__recv_procnum() call), with the status code still sitting in the
send buffer.
Try the following patch:
--- lib/db/dbmi_base/xdr.c 15 Oct 2007 05:24:17 -0000 1.6
+++ lib/db/dbmi_base/xdr.c 22 Oct 2007 21:39:28 -0000
@@ -88,6 +88,9 @@
int db__recv(void *buf, size_t size)
{
#if USE_STDIO
+#ifdef USE_BUFFERED_IO
+ fflush(_send);
+#endif
return fread(buf, 1, size, _recv) == size;
#elif USE_READN
return readn(fileno(_recv), buf, size) == size;
--
Glynn Clements <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
