Displaying 3 results from an estimated 3 matches for "3dbuf".
Did you mean:
dbuf
2019 Dec 04
0
error in parallel:::sendMaster
...;> (gdb) n
>>> 693 if (writerep(master_fd, &len, sizeof(len)) !=3D sizeof(len)) {
>>> (gdb) info locals
>>> len =3D 538
>>> b =3D <optimized out>
>>> n =3D <optimized out>
>>> (gdb) s
>>> writerep (fildes=3D6, buf=3Dbuf at entry=3D0x7ffdd6da7db0, nbyte=3Dnbyte at e=
>> ntry=3D8)
>>> at fork.c:653
>>> 653 {
>>> (gdb) info args
>>> fildes =3D 6
>>> buf =3D 0x7ffdd6da7db0
>>> nbyte =3D 8
>>> (gdb) n
>>> 654 size_t wbyte =3D 0;
>...
2019 Dec 04
0
error in parallel:::sendMaster
...;> (gdb) n
>>> 693 if (writerep(master_fd, &len, sizeof(len)) !=3D sizeof(len)) {
>>> (gdb) info locals
>>> len =3D 538
>>> b =3D <optimized out>
>>> n =3D <optimized out>
>>> (gdb) s
>>> writerep (fildes=3D6, buf=3Dbuf at entry=3D0x7ffdd6da7db0, nbyte=3Dnbyte at e=
>> ntry=3D8)
>>> at fork.c:653
>>> 653 {
>>> (gdb) info args
>>> fildes =3D 6
>>> buf =3D 0x7ffdd6da7db0
>>> nbyte =3D 8
>>> (gdb) n
>>> 654 size_t wbyte =3D 0;
>...
2019 Nov 28
1
error in parallel:::sendMaster
Hi Andreas,
thank you very much, good job finding it was EBADF. Now the question is
why the pipe has been closed prematurely; it could be accidentally by R
(a race condition in the cleanup code in fork.c) or possibly by some
other code running in the same process (maybe the R program itself or
some other code it runs). Maybe we can take this off the list and come
back when we know the cause