Re: /opt/bin/find error

[James Youngman]

Please don't send off-list replies.   It compromises the ability of
the members of the list to help you.

The evidence is puzzling, though.   Comments below.

On Tue, Oct 14, 2014 at 1:27 AM, Steve Forman <address@hidden> wrote:
> /opt/bin # opkg info findutils
> Package: findutils
> Version: 4.5.14-1
> Depends: libc
> Status: install user installed
> Section: utils
> Architecture: mipselsf
> Maintainer: Entware team, entware.wl500g.info
> MD5Sum: c030ea9b50990b4b1d2b48a546bea9d3
> Size: 154478
> Filename: findutils_4.5.14-1_mipselsf.ipk
> Source: feeds/rtndev/findutils
> Description: GNU Find Utilities are the basic directory searching utilities
> of the GNU OS.
> Installed-Time: 1413187009
>
> It was an opkg install.
> /opt/bin # uname -a
> Linux Venus 2.6.12.6-VENUS #24 Tue Aug 17 22:26:54 CST 2010 mips GNU/Linux

Is this platform self-hosting?     I'm asking because I don't yet
understand what is happening here and we may need to use a debugger or
try code changes in order to diagnose the problem.

Did you try asking the "Entware team" for help in diagnosing the
problem?      I ask partly because, according to the strace output,
the version of GNU find you are using does something that the "stock"
version (usually, see below) does not - it calls "fork" without there
being -exec/-ok/execdir/-okdir on the command line.


> /opt/bin # strace /opt/bin/find
> execve("/opt/bin/find", ["/opt/bin/find"], [/* 20 vars */]) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000,
> -1, 0) = 0x2aaaf000
> stat("/opt/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=9737, ...}) = 0
> open("/opt/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> mmap(NULL, 9737, PROT_READ, MAP_SHARED, 3, 0) = 0x2aab0000
> close(3)                                = 0
> open("/opt/lib/libm.so.0", O_RDONLY)    = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=90044, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000,
> -1, 0) = 0x2aab3000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\240\25\0\0004\0\0\0"...,
> 4096) = 4096
> mmap(NULL, 151552, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aac0000
> mmap(0x2aac0000, 84352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
> 0x2aac0000
> mmap(0x2aae4000, 2868, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
> 0x14000) = 0x2aae4000
> close(3)                                = 0
> munmap(0x2aab3000, 4096)                = 0
> open("/opt/lib/libc.so.0", O_RDONLY)    = 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=693596, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000,
> -1, 0) = 0x2aab3000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\220\262\0\0004\0\0\0"...,
> 4096) = 4096
> mmap(NULL, 733184, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aae5000
> mmap(0x2aae5000, 634476, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
> 0x2aae5000
> mmap(0x2ab90000, 8040, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
> 0x9b000) = 0x2ab90000
> mmap(0x2ab92000, 20908, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ab92000
> close(3)                                = 0
> munmap(0x2aab3000, 4096)                = 0
> open("/lib/libc.so.0", O_RDONLY)        = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=358952, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000,
> -1, 0) = 0x2aab3000
> read(3,
> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0000\5\0\0004\0\0\0"...,
> 4096) = 4096
> mmap(NULL, 638976, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ab98000
> mmap(0x2ab98000, 352828, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
> 0x2ab98000
> mmap(0x2ac2e000, 5040, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
> 0x56000) = 0x2ac2e000
> mmap(0x2ac30000, 14952, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ac30000
> close(3)                                = 0
> munmap(0x2aab3000, 4096)                = 0
> munmap(0x2aab0000, 9737)                = 0
> stat("/opt/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=31696, ...})
> = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4000000,
> -1, 0) = 0x2aab0000
> set_thread_area(0x2aab72d0)             = -2123718656
> mprotect(0x2ab90000, 4096, PROT_READ)   = 0
> mprotect(0x2aabe000, 4096, PROT_READ)   = 0
> ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
> brk(0)                                  = 0x450000
> brk(0x451000)                           = 0x451000

Everything above this point seems to be the dynamic library loader
loading the libraries.   It's not quite the same on my development
system, but that is not at all a concern.


> 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:

/tmp/t$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
obase=2
4294967207
11111111111111111111111110100111
obase=10
ibase=2
-(1011000)-1
-89

But I don't have a hypothesis right now that clearly explains what is
happening here.

The gnulib function savewd does something a bit like this, but I don't
think the find binary you are using should be using that function.
And certainly not directly.

> svr4_fork()                             = 4004
> /opt/bin/findsvr4_gtime()                            = 4004
> : svr4_fork()                             = 4004
> ‘.’svr4_wait()                             = -1 ERRNO_4004 (Unknown error
> 4004)
> : svr4_fork()                             = 4004
> Unknown error -89svr4_sbreak()                           = 4004

I see the interesting value -89 there.   MIPS seems to pass the system
call number in $v0 (http://www.linux-mips.org/wiki/Syscall) and use
the same register for return values.   Hence if -89 is returned from a
system call and then a syscall is entered again without resetting $v0,
we might see these symptoms.   But then, this seems a very strange
thing for a piece of code to do.



> svr4_exit()                             = 4133
> svr4_syscall()                          = 4006
> svr4_syscall()                          = -1 ERRNO_4006 (Unknown error 4006)
> svr4_syscall()                          = 4006
> svr4_syscall()                          = -1 ERRNO_4246 (Unknown error 4246)
> +++ exited with 1 +++
>
>
>
> On 10/13/2014 12:27 PM, James Youngman wrote:
>>
>> On Mon, Oct 13, 2014 at 2:40 PM, Dale R. Worley <address@hidden>
>> wrote:
>>>>
>>>> From: Steve Forman <address@hidden>
>>>>
>>>> I'm getting this error and can find absolutely no information on it.
>>>> find: ‘.’: Unknown error -89
>>>>
>>>> No matter what path I use I always get this message.
>>>> Any ideas?
>>
>> No, not on the basis of what you wrote (as many people have already
>> mentioned).
>>
>> What version of findutils are you running?   How was it configured and
>> built?    What operating system are you running it on?   What specific
>> command-line did you use?  What is the result of /opt/bin/find
>> --version?
>>
>> What happens if you run the same command under a system-call tracer
>> (such as strace, on most Linux-based systems)?
>>
>>
>> James.
>>
>



-- 
--
This email is intended solely for the use of its addressee, sender,
and any readers of a mailing list archive in which it happens to
appear.   If you have received this email in error, please say or type
three times, "I believe in the utility of email disclaimers," and then
reply to the author correcting any spellings (and, optionally, any
incorrect spellings), accompanying these with humorous jests about the
author's parentage.   If you are not the addressee, you are
nevertheless permitted to both copy and forward this email since
without such permissions email systems are unable to transmit email to
anybody, intended recipient or not.  To those still reading by this
point, the author would like to apologise for being unable to maintain
a consistent level of humour throughout this disclaimer.  Contents may
settle during transit.  Do not feed the animals.