[GRASS-dev] v.what.rast speedup

[Markus Neteler]

Glynn Clements wrote:
> 
> Markus Neteler wrote:
>> Glynn Clements 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:

0x0000003d43abfa10 in __read_nocancel () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003d43abfa10 in __read_nocancel () from /lib64/libc.so.6
#1  0x0000003d43a69827 in _IO_new_file_underflow () from /lib64/libc.so.6
#2  0x0000003d43a6852e in _IO_file_xsgetn_internal () from /lib64/libc.so.6
#3  0x0000003d43a5f0c2 in fread () from /lib64/libc.so.6
#4  0x00002aaaaacfb8b8 in db__recv (buf=0x7fffb4953a5c, size=4) at xdr.c:91
#5  0x00002aaaaacfc678 in db__recv_int (n=0x7fffb4953a5c) at xdrint.c:23
#6  0x00002aaaaacf998e in db__recv_return_code (ret_code=0x7fffb4953a5c) at
ret_codes.c:27
#7  0x00002aaaab3ae0fc in db_start_driver (name=0x114a9d10 "dbf") at
start.c:321
#8  0x00002aaaab3ac91e in db_start_driver_open_database (drvname=0x114a9d10
"dbf",
    dbname=0x114a9cd0 "/ssi0/ssi/neteler/grassdata/spearfish60/user1/dbf/")
at db.c:20
#9  0x0000000000401bc0 in main (argc=4, argv=0x7fffb4954bd8) at main.c:125
(gdb)

Using strace:
...
open("/nfsmnt/bartok0/ssi/neteler/software/cvsgrass63/dist.x86_64-unknown-linux-gnu/driver/db/",
O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 15
fstat(15, {st_mode=S_IFDIR|0771, st_size=4096, ...}) = 0
fcntl(15, F_SETFD, FD_CLOEXEC)          = 0
getdents(15, /* 8 entries */, 4096)     = 208
getdents(15, /* 0 entries */, 4096)     = 0
close(15)                               = 0
pipe([15, 16])                          = 0
pipe([17, 18])                          = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x2aaaacfa6110) = 22602
close(15)                               = 0
close(18)                               = 0
fcntl(16, F_GETFL)                      = 0x1 (flags O_WRONLY)
fstat(16, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aaab04ae000
lseek(16, 0, SEEK_CUR)                  = -1 ESPIPE (Illegal seek)
fcntl(17, F_GETFL)                      = 0 (flags O_RDONLY)
fstat(17, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aaab04af000
lseek(17, 0, SEEK_CUR)                  = -1 ESPIPE (Illegal seek)
read(17,  <unfinished ...>

Does this tell you anything?

Markus
-- 
View this message in context: http://www.nabble.com/r.random%3A-now-with-optional-cover-map-parameter-tf4634057.html#a13351492
Sent from the Grass - Dev mailing list archive at Nabble.com.