GNU bug report logs -
#10305
coreutils-8.14, "rm -r" fails with EBADF
Previous Next
Full log
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
...
>> but what I really need to know is what happened just prior, in fts_read.
>> Can you run gdb, set a breakpoint in fts_read and show us the result of stepping
>> through fts_read? That would be most useful.
>
> Sorry, no gdb, the debugger here is calls eInspect (but is similar to
> gdb, as far as I know).
> It goes thru fts_read() the 1st time without problem, on 2nd round
> fts_build(sp, BREAD) in ~/coreutils-8.14/lib/fts.c line 903 returns
> NULL, then the subsequent rm_fts (fts, ent, x) fails. It goues trhi
> fts_read() 2 more times after that.
There are three places in fts_build that directly set FTS_STOP:
- fts_palloc failure (i.e., virtual memory exhausted, not likely)
- found a file name longer than SIZE_MAX (not likely)
- failure to restore working directory:
/*
* If descended after called from fts_children or after called from
* fts_read and nothing found, get back. At the root level we use
* the saved fd; if one of fts_open()'s arguments is a relative name
* to an empty directory, we wind up here with no other way back. If
* can't get back, we're done.
*/
if (!continue_readdir && descend && (type == BCHILD || !nitems) &&
(cur->fts_level == FTS_ROOTLEVEL
? RESTORE_INITIAL_CWD(sp)
: fts_safe_changedir(sp, cur->fts_parent, -1, ".."))) {
cur->fts_info = FTS_ERR;
SET(FTS_STOP);
fts_lfree(head);
return (NULL);
}
If you can debug it further to narrow down what/how it is failing,
eventually we'll find the cause.
This bug report was last modified 12 years and 110 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.