> From: James Youngman <j...@gnu.org>
> > open(".", O_RDONLY|O_LARGEFILE) = 3
> > fcntl64(3, F_GETFD) = 0
> > fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> > uname({sys="Linux", node="Venus", ...}) = 0
> > ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> > gettimeofday({1413246219, 805489}, NULL) = 0
> > brk(0x452000) = 0x452000
> > ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> > brk(0x453000) = 0x453000
> > brk(0x454000) = 0x454000
>
> The system calls above look right. find is saving its initial
> working directory and the current time.
>
> However, everything below this point looks very strange.
>
> > syscall_4294967207(0xffffff9c, 0x453080, 0x7fdd8a00, 0x1, 0x2ab99470,
> > 0x4016fd, 0) = -1 (errno 4005)
>
> 4294967207 is certainly a strange number. It looks like -89 in two's
> complement:
Yikes. This isn't my area of expertise, looking at my
/usr/include/asm/unistd.h, I see that system calls are numbered with
positive numbers. And the fact that trace prints this number as
4294967207 suggests that on the target system, system calls are
numbered with positive numbers. Perhaps the program has gone
completely out of control at this point?
Is there a way to verify that the find binary is correct?
What happens if you downgrade to findutils_4.5.12? (I see it on
http://entware.wl500g.info/binaries/mipselsf/archive/, so it probably
exists.)
What happens if you build find from source?
Dale
