bug-findutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: endless loop in /usr/bin/find ?


From: Dave Howorth
Subject: Re: endless loop in /usr/bin/find ?
Date: Mon, 20 Jun 2005 11:59:16 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk

James Youngman wrote:
> That's what the bug report I'm working from said.  I have not
> personally tested 4.1.20 to see if it is affected by this problem.

I just ran that test to make sure. There was no problem with 4.1.20, so it's very likely something different.

JY:
I think then that you're seeing a different problem.  If it happens
again, could you
        1. check the state of the process using "ps" (probably
           D, S or R)
        2. get a snapshot of what it's doing with "strace -p" and/or
           "ltrace -p"
        3.  and then kill it with "SIGQUIT"

Raise a bug against findutils on the Savannah bug reporting page
(http://savannah.gnu.org/bugs/?group=findutils) and attach

        1. The output of ps, strace, ltrace etc.
        2. the 'find' executable you are using
        3. the resulting core file (assuming you are running
           with "ulimit -c unlimited").

JY:
> Since find changes working directory as it goes, this core file will
> be dropped in the directory that find was searching when the problem
> occurred.  Knowing if there's anything special about that directory
> might also be useful.  Of course, this also means that you will need
> to search for the core file.  If the directory isn't writable, you
> might even not get a core dump.

The info for 1 & 2 were in my original email, repeated below. Sadly, I didn't kill it with a QUIT and there's no core file on the system. If it happens again I'll drop core and report where I found it. Would you like me to file an incomplete bug report now, or should I wait until (if) I see it again and have a core file?

Thanks again for your rapid response.

Cheers, Dave

=============================
 From top, find seems to be very busy doing something:

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  5106 root      39  15  2928  528 2752 R 99.9  0.0   1792:15 find

 From strace, find isn't interacting with the system at all. In
 particular it's not examining files or directories :(

  suse1:~ # strace -p 5106
  Process 5106 attached - interrupt to quit

 (no output despite leaving it for quite a while, so my conclusion is
 that find is in an infinite loop)






reply via email to

[Prev in Thread] Current Thread [Next in Thread]