[GRASS-dev] v.what.rast speedup
glynn at gclements.plus.com
Mon Oct 22 17:45:28 EDT 2007
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.:
$ pidof v.what.rast
$ gdb $GISBASE/bin/v.what.rast
> attach <pid of v.what.rast process>
$ pidof dbf
$ gdb $GISBASE/driver/db/dbf
> attach <pid of dbf process>
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
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)
return fread(buf, 1, size, _recv) == size;
return readn(fileno(_recv), buf, size) == size;
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev