From: Robert W. <ro...@us...> - 2001-06-12 16:15:00
|
The "readdir01" test fails consistently on my RedHat 7.1 and SuSE 7.1 installs with the 2.4.5 kernel: readdir01 0 WARN : signal() failed for signal 32. error:22 Invalid argument. readdir01 0 WARN : signal() failed for signal 33. error:22 Invalid argument. readdir01 0 WARN : signal() failed for signal 34. error:22 Invalid argument. readdir01 1 FAIL : readir(test_dir) Failed on try 10, errno=22 : Invalid argument readdir01 2 PASS : found all 10 that were created However on my TurboLinux 6.5 installed with 2.4.5 it passes: readdir01 0 WARN : signal() failed for signal 32. error:0 Success. readdir01 0 WARN : signal() failed for signal 33. error:0 Success. readdir01 0 WARN : signal() failed for signal 34. error:0 Success. readdir01 1 PASS : found all 10 that were created Just wondering if anyone else has seen this. - Robbie Robert V. Williamson Linux System Test Linux Technology Center Phone: (512) 838-9295 T/L: 638-9295 Email: ro...@us... |
From: Nathan S. <ns...@sg...> - 2001-06-12 17:09:33
|
On Tue, Jun 12, 2001 at 11:14:36AM -0500, Robert Williamson wrote: > The "readdir01" test fails consistently on my RedHat 7.1 and SuSE 7.1 > installs with the 2.4.5 kernel: > readdir01 0 WARN : signal() failed for signal 32. error:22 Invalid > argument. > readdir01 0 WARN : signal() failed for signal 33. error:22 Invalid > argument. > readdir01 0 WARN : signal() failed for signal 34. error:22 Invalid > argument. > readdir01 1 FAIL : readir(test_dir) Failed on try 10, errno=22 : > Invalid argument > readdir01 2 PASS : found all 10 that were created > > However on my TurboLinux 6.5 installed with 2.4.5 it passes: > readdir01 0 WARN : signal() failed for signal 32. error:0 Success. > readdir01 0 WARN : signal() failed for signal 33. error:0 Success. > readdir01 0 WARN : signal() failed for signal 34. error:0 Success. > readdir01 1 PASS : found all 10 that were created The signal warnings, I would guess, are from the lack of realtime signal support. As for the failure and pass, this is really wrong. readdir() is supposed to return NULL when it doesn't have any entries left, not fail. Is this the same kernel that you copied onto different systems? If so, I would point at libc rather than the kernel. One thing to be aware of, the directory that readdir01 uses for testing is $TMPDIR if it exists or /tmp. -- Nate Straz ns...@sg... sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ |
From: Paul L. <pl...@au...> - 2001-06-15 20:31:30
|
> The signal warnings, I would guess, are from the lack of realtime signal > support. As for the failure and pass, this is really wrong. readdir() > is supposed to return NULL when it doesn't have any entries left, not > fail. > > Is this the same kernel that you copied onto different systems? If so, > I would point at libc rather than the kernel. > > One thing to be aware of, the directory that readdir01 uses for testing > is $TMPDIR if it exists or /tmp. The problem with readdir01 is that it isn't checking the return value of readdir(). Minor bug, all it's doing is checking errno. readdir() passed, but errno is 22 from the call to sigaction in tst_sig.c. I'm not really sure why it's having a problem with those three signals, but the really odd thing here is that the glibc in turbolinux is returning errno=0 even though sigaction is failing with an invalid signal. The glibc on rh and suse is newer though, so it could be something that just got fixed in these newer versions. -Paul Larson |
From: Nathan S. <ns...@sg...> - 2001-06-12 19:53:56
|
On Tue, Jun 12, 2001 at 12:17:53PM +0000, Paul Larson wrote: > The problem with readdir01 is that it isn't checking the return value of > readdir(). Minor bug, all it's doing is checking errno. readdir() passed, > but errno is 22 from the call to sigaction in tst_sig.c. I'm not really sure > why it's having a problem with those three signals, but the really odd thing > here is that the glibc in turbolinux is returning errno=0 even though > sigaction is failing with an invalid signal. The glibc on rh and suse is > newer though, so it could be something that just got fixed in these newer > versions. I am checking the return of readdir(), it's part of the while condition. According to the readdir(3) man page (from Debian Sid) RETURN VALUE The readdir() function returns a pointer to a dirent structure, or NULL if an error occurs or end-of-file is reached. So... since the return value for finished and error are the same, I would speculate that the errno value must be set by readdir() to ESUCCESS (i.e. 0) if the condition is end-of-file. I would suggest checking the differences between RH, SuSe, and TL libc packages. FYI, readdir01 runs fine on my Debian box and my RH XFS-1.0 system. Output below. Debian Sid nstraz@maine cvs/ltp/tests% ldd --version ldd (GNU libc) 2.2.3 Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. nstraz@maine cvs/ltp/tests% uname -a Linux maine 2.4.3 #1 Mon Apr 2 09:05:04 CDT 2001 i686 unknown nstraz@maine cvs/ltp/tests% ./readdir01 readdir01 1 PASS : found all 10 that were created RH XFS-1.0 nstraz@permit ~/tests% ldd --version ldd (GNU libc) 2.2.2 Copyright (C) 1999 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. nstraz@permit ~/tests% uname -a Linux permit 2.4.2-SGI_XFS_0.10.3smp #1 SMP Fri Apr 13 22:47:26 CDT 2001 i686 unknown nstraz@permit ~/tests% ./readdir01 readdir01 1 PASS : found all 10 that were created -- Nate Straz ns...@sg... sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ |
From: Andreas J. <aj...@su...> - 2001-06-13 08:37:34
|
Nathan Straz <ns...@sg...> writes: > On Tue, Jun 12, 2001 at 12:17:53PM +0000, Paul Larson wrote: >> The problem with readdir01 is that it isn't checking the return value of >> readdir(). Minor bug, all it's doing is checking errno. readdir() passed, >> but errno is 22 from the call to sigaction in tst_sig.c. I'm not really sure >> why it's having a problem with those three signals, but the really odd thing >> here is that the glibc in turbolinux is returning errno=0 even though >> sigaction is failing with an invalid signal. The glibc on rh and suse is >> newer though, so it could be something that just got fixed in these newer >> versions. > > I am checking the return of readdir(), it's part of the while condition. > According to the readdir(3) man page (from Debian Sid) > > RETURN VALUE > The readdir() function returns a pointer to a dirent > structure, or NULL if an error occurs or end-of-file is > reached. > > So... since the return value for finished and error are the same, I > would speculate that the errno value must be set by readdir() to > ESUCCESS (i.e. 0) if the condition is end-of-file. I would suggest > checking the differences between RH, SuSe, and TL libc packages. > > FYI, readdir01 runs fine on my Debian box and my RH XFS-1.0 system. > Output below. This was fixed just recently in glibc, the fixes will be in glibc 2.2.4 (you might have a newer CVS libc). Andreas 2001-05-09 Andreas Schwab <sc...@su...> * sysdeps/unix/readdir.c: Make sure we don't modify errno when we reached EOF. -- Andreas Jaeger SuSE Labs aj...@su... private aj...@ar... http://www.suse.de/~aj |
From: Paul L. <pl...@au...> - 2001-06-13 16:35:35
|
> This was fixed just recently in glibc, the fixes will be in glibc > 2.2.4 (you might have a newer CVS libc). > > Andreas > > 2001-05-09 Andreas Schwab <sc...@su...> > > * sysdeps/unix/readdir.c: Make sure we don't modify errno when we > reached EOF. This doesn't really sound like the problem we're seeing here though. It looks like some other function (sigaction in this case) is failing and setting errno=22. That is caught, and a warning is issued, but the program isn't stopped just because sigaction didn't like one of the signals requested. Fall through until we eventually reach the readdir() call. Since this readdir returns a struct dirent* rather than a return code (As Nate pointed out), the errno is checked to see if an error occurred. An error did not occur, so errno didn't get changed from what it was (22). Even though readdir didn't have a problem, the testcase thinks it did because it didn't get reset back to 0. There is another readdir that is the system call (see man 2 readdir). This one takes 3 argments, the fd, the dirent*, and a count that is ignored. This readdir() returns -1 on failure though. Anyone know of any good/bad to doing it this way? Still trying to reproduce this problem on another machine though... I am still having the "it works on my machine" syndrome as well. -Paul Larson |