Subject: RE: bug#10305: coreutils-8.14, "rm -r" fails with EBADF

From: "Joachim Schmitz" <[email-masked]>
Date: Sun, 18 Dec 2011 11:31:20 +0100

> From: Paul Eggert [mailto:[email-masked]]
> Sent: Saturday, December 17, 2011 1:27 AM
> To: Joachim Schmitz
> Cc: 'Eric Blake'; 'Jim Meyering'; [email-masked]; [email-masked]
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
> 
> On 12/16/11 13:21, Joachim Schmitz wrote:
> > The standalone version works just fine.
> 
> That's too bad.  I'm afraid there's no magic here: we need to see what system
> calls are being executed by 'rm', and in what order, and what arguments they
> are being given, and what their results are, so that we can figure out what's
> going wrong.  Since NonStop doesn't have 'truss', I guess you'll need to put a
> breakpoint on every system call and see what its arguments are and what it
> returns, starting with the system call that opens the directory.  Or, you can put
> wrappers around each system call in the source code, and have the wrappers
> send diagnostics to stderr.

I did some more debugging: it seems to go wrong in fcntl.c, line 194:

            /* Haiku alpha 2 loses fd flags on original.  */
            int flags = fcntl (fd, F_GETFD);    <==
            if (flags < 0)
              {
                result = -1;
                break;
              }

that fcntl() returns a -1 with errno set to EBADF.
For some reason I can step into that fcntl(), guess it is calling the system's fcntl here?

Stack trace:
7 rpl_fcntl() fcntl.c:194
6 dup_safer() dup-safer.c:33
5 fts_build() fts.c:1384
4 fts_read() ftc.c:902
3 rm() remove.c:598
2 main() rm.c:343
1 _MAIN()

Bye, Jojo