[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10305: coreutils-8.14, "rm -r" fails with EBADF
From: |
Joachim Schmitz |
Subject: |
bug#10305: coreutils-8.14, "rm -r" fails with EBADF |
Date: |
Wed, 21 Dec 2011 18:12:26 +0100 |
> From: Eric Blake [mailto:address@hidden
> Sent: Wednesday, December 21, 2011 5:28 PM
> To: Jim Meyering
> Cc: Joachim Schmitz; address@hidden; 'Paul Eggert'; bug-
> address@hidden
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 12/21/2011 09:06 AM, Jim Meyering wrote:
> >>
> >> Where to go now?
> >>
> >> Resorting to wild guesses, I tried all 3 members of struct DIR as
> >> DIF_FD_MEMBER_NAME, no change to the EBADF
> >
> > Write a small test program that opens say four directories, to get one
> > DIR* pointer for each. Then print a table of the DIR member values.
> > Maybe you'll see a pattern, i.e., how to derive an FD number from
> > those dd1,2,3 fields.
Yes, indeed, thanks for that idea (should have been mine):
It got to be dd1, only it is not an fd but something called fnum and these a)
start counting with 1 rather than 0 and b) have 1 and 2 being root and CPD,
followed by 3,4 and 5 being stdin, stdout, stderr... it seems fnum -3 == fd
> If the NonStop opendir() does not open a directory fd under the hood, then
> maybe we should wrap opendir() so that the gnulib rpl_opendir() always opens
> a directory at the same time; at which point the gnulib rpl_dirfd merely
> returns
> that directory fd.
Sounds good, but, to be honest, You lost me here ...
> Also, does NonStop have anything like Linux' /proc/self/fd
No, unfortunatly
> or lsof, for reverse
> engineering which fds a process has open and on what files? Is there an
Hmm... not lsof, but other methods to find out who has which file open and
which file is opened by whom.
Reveals , when testing with rm, that my theory from above seems correct, that
dir gets fnum=7, the value I see in struct DIR's member dd1, see below.
> equivalent to strace functionality for tracking all syscalls made by libc?
Not that I'd know of.
So let's see whether taking that fnum (AKA "dd1") and subtracting 3 makes it a
proper fd.
But this is something for tomorrow...
Bye, Jojo
PS: one of these commands is 'pstate' and here's the output (somewhat verbose,
the relevant part at the end)
$ pstate 728694845
PSTATE - T0705AAF (H01) (03MAY2008)
(C)1981 Tandem (C)2004 Hewlett Packard Development Company, L.P.
PSTATE for Guardian T06 on December 21, 2011 10:55:28.02 (LCT)
Target process: pin 720 in cpu 1, \HPITUG.$:1:720:20012474
OSS Pid: 728694845
loadfile type: MAYSETBPT,OSSPROCESS,PICELFPRG
loadfile name: /usr/local/Floss/coreutils-8.14/src/rm
\HPITUG.$SAS106.ZYQL0CAL.Z0009JRT
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zossfdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zi18ndll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zicnvdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zutildll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zcrtldll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zosskdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zcredll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zosscdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zsecdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zossedll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zosshdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zrlddll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zinetdll
loadfile type: OSSPROCESS,IMPLIB,PICELFDLL
loadfile name: /G/system/sys05/initdll
loadfile type: OSSPROCESS,IMPLIB,PICELFDLL
loadfile name: /G/system/sys05/mcpdll
swap: \HPITUG.$SAS106.#0
extended swap:
segment: Id: 2046
Add: x6CA00000 Size: 147456 Max: 2097152
Flat,Unaliased,KMS Backed
home terminal: \HPITUG.$ZPTY.#ZWN0115
Initial priority was 150, current priority is 150.
Process Wait State: x0000
waiting on :
Process access ID (PAID): ITUGLIB .JOJO , 100,4
Process State: x0009
INSPECT BREAKPOINT
Creator proc : , Id: ITUGLIB .JOJO , 100,4
Process Creation Time: December 21, 2011 10:52:52.420787 (LCT)
Process Execution Time: 0:0:0.001262
Only the process creator may stop this process.
No-one has tried to stop this process.
Procedure call trace:
rpl_opendir + 0x90 (UCr)
opendir_safer + 0x90 (UCr)
fd_clone_opendir + 0x3D0 (UCr)
fdopendir_with_dup + 0x340 (UCr)
fdopendir + 0xD0 (UCr)
opendirat + 0x230 (UCr)
fts_build + 0x7A0 (UCr)
fts_read + 0xE50 (UCr)
rm + 0x210 (UCr)
main + 0x1290 (UCr)
_MAIN + 0x80 (UCr)
Process memory values and other counters.
PFS Current 13624, Size 31384, Max 33554432
Main Stack Origin x70000000, Size 262144, Max 2097152
Priv Stack Origin x6DFE0000, Size 65536, Max 901120
Heap Origin x080CA800, Size 32768, Max 1609783296
Globals Origin x08000000, Size 827392
KMSF Guarantee 0
Resident memory pages 41
Messages Sent 51, Received 2
$RECEIVE Current QLength 0
Page faults 42
Fnum Filename Type Styp Lsterr
---- --------------------------------------- ----------- ---- ------
7 POSIX dir open 0
/tmp/foo
6 OSS open 0
/tmp/foo
5 \HPITUG.$ZPTY.#ZWN0115 OSS open 0
/G/zpty/#zwn0115
4 \HPITUG.$ZPTY.#ZWN0115 OSS open 0
/G/zpty/#zwn0115
3 \HPITUG.$ZPTY.#ZWN0115 OSS open 0
/G/zpty/#zwn0115
2 Current dir 0
/home/jojo
1 Root dir 0
/
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, (continued)
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Paul Eggert, 2011/12/16
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Joachim Schmitz, 2011/12/16
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Paul Eggert, 2011/12/16
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Joachim Schmitz, 2011/12/18
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Paul Eggert, 2011/12/18
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Joachim Schmitz, 2011/12/19
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Paul Eggert, 2011/12/19
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Joachim Schmitz, 2011/12/21
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Jim Meyering, 2011/12/21
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Eric Blake, 2011/12/21
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF,
Joachim Schmitz <=
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Eric Blake, 2011/12/21
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Joachim Schmitz, 2011/12/22
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Joachim Schmitz, 2011/12/21
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Paul Eggert, 2011/12/21
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Eric Blake, 2011/12/21
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Joachim Schmitz, 2011/12/22
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Paul Eggert, 2011/12/22
- bug#10305: coreutils-8.14, "rm -r" fails with EBADF, Joachim Schmitz, 2011/12/19