Hi jan,
As you mentioned I checked the strace output. I was not knowing how to analyze
it. so I compared strace in a normal pc and my test machine. I saw a strange
thing.
rt_sigaction(SIGPWR, {0x403b30, [], SA_RESTORER|SA_RESTART, 0x38e7a329a0},
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGSYS, {0x403b30, [], SA_RESTORER|SA_RESTART, 0x38e7a329a0},
{SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGRT_16, {0x403b30, [], SA_RESTORER|SA_RESTART, 0x38e7a329a0},
{SIG_DFL, [], 0}, 8) = 0
getpid() = 16161
mkdir("/tmp/fstZJB5At", 0700) = 0
getgid() = 0
chown("/tmp/fstZJB5At", 4294967295, 0) = 0
chmod("/tmp/fstZJB5At", 0777) = 0
chdir("/tmp/fstZJB5At") = 0
fstatfs(4294967295, 0x608ec0) = -1 EBADF (Bad file descriptor)
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f12484f3000
write(1, "fstatfs02 1 TPASS : expect"..., 77fstatfs02 1 TPASS :
expected failure - errno = 9 : Bad file descriptor
) = 77
fstatfs(1, 0xffffffffffffffff) = -1 EFAULT (Bad address)
write(1, "fstatfs02 2 TPASS : expect"..., 70fstatfs02 2 TPASS :
expected failure - errno = 14 : Bad address
) = 70
stat("/tmp/fstZJB5At", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
stat("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
chdir("/tmp") = 0
lstat("/tmp/fstZJB5At", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
open("/tmp/fstZJB5At", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
getdents(3, /* 2 entries */, 32768) = 48
getdents(3, /* 0 entries */, 32768) = 0
close(3) = 0
lstat("/tmp/fstZJB5At", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
unlink("/tmp/fstZJB5At") = -1 EISDIR (Is a directory)
rmdir("/tmp/fstZJB5At") = 0
exit_group(0) = ?
[root@localhost fstatfs]#
Now the output of test system
rt_sigaction(SIGRT_75, {0x1000000000000012, [RT_38 RT_39 RT_40 RT_41 RT_43
RT_45 RT_46 RT_48 RT_53 RT_56 RT_57 RT_58 RT_62 RT_63 RT_65 RT_67 RT_69 RT_71],
SA_INTERRUPT|0x4dd0}, {SIG_DFL, [], 0}, 16) = 0
rt_sigaction(SIGRT_76, {0x1000000000000012, [RT_38 RT_39 RT_40 RT_41 RT_43
RT_45 RT_46 RT_48 RT_53 RT_56 RT_57 RT_58 RT_62 RT_63 RT_65 RT_67 RT_69 RT_71],
SA_INTERRUPT|0x4dd0}, {SIG_DFL, [], 0}, 16) = 0
rt_sigaction(SIGRT_77, {0x1000000000000012, [RT_38 RT_39 RT_40 RT_41 RT_43
RT_45 RT_46 RT_48 RT_53 RT_56 RT_57 RT_58 RT_62 RT_63 RT_65 RT_67 RT_69 RT_71],
SA_INTERRUPT|0x4dd0}, {SIG_DFL, [], 0}, 16) = 0
rt_sigaction(SIGRT_78, {0x1000000000000012, [RT_38 RT_39 RT_40 RT_41 RT_43
RT_45 RT_46 RT_48 RT_53 RT_56 RT_57 RT_58 RT_62 RT_63 RT_65 RT_67 RT_69 RT_71],
SA_INTERRUPT|0x4dd0}, {SIG_DFL, [], 0}, 16) = 0
rt_sigaction(SIGRT_79, {0x1000000000000012, [RT_38 RT_39 RT_40 RT_41 RT_43
RT_45 RT_46 RT_48 RT_53 RT_56 RT_57 RT_58 RT_62 RT_63 RT_65 RT_67 RT_69 RT_71],
SA_INTERRUPT|0x4dd0}, {SIG_DFL, [], 0}, 16) = 0
gettimeofday({1403526017, 77215}, NULL) = 0
getpid() = 11117
mkdir("/tmp/fstwRp89g", 0700) = 0
getgid() = 501
chown("/tmp/fstwRp89g", -1, 501) = 0
chmod("/tmp/fstwRp89g", 0777) = 0
chdir("/tmp/fstwRp89g") = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x5563a59000
write(1, "fstatfs02 1 TFAIL : call s"..., 68fstatfs02 1 TFAIL :
call succeeded unexpectedly 366743313008
) = 68
write(1, "fstatfs02 2 TFAIL : call s"..., 57fstatfs02 2 TFAIL :
call succeeded unexpectedly 1
) = 57
stat("/tmp/fstwRp89g", {st_mode=S_IFDIR|0777, st_size=40, ...}) = 0
stat("/", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
chdir("/tmp") = 0
lstat("/tmp/fstwRp89g", {st_mode=S_IFDIR|0777, st_size=40, ...}) = 0
open("/tmp/fstwRp89g", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) =
3
fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC)
getdents(3, /* 2 entries */, 32768) = 48
getdents(3, /* 0 entries */, 32768) = 0
close(3) = 0
lstat("/tmp/fstwRp89g", {st_mode=S_IFDIR|0777, st_size=40, ...}) = 0
unlink("/tmp/fstwRp89g") = -1 EISDIR (Is a directory)
rmdir("/tmp/fstwRp89g") = 0
exit_group(1) = ?
I am not seeing fstatfs call itself when comparing the system call. I hope this
is the reason?
Also fstatfs02 was working fine. Only fstatfs02_64 was having the issue. I saw
in ../utils/newer_64.mk makefile. It will be good if you tell little more about
the 64 here.
I am working on 2.6.32.46 kernel.
Regards
Ajoy
-----Original Message-----
From: Jan Stancek [mailto:jstan...@redhat.com]
Sent: Monday, June 23, 2014 5:13 PM
To: Ajoymon Joseph
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] fstatfs02 issue on mips64
----- Original Message -----
> From: "Ajoymon Joseph" <ajoy.jos...@lnttechservices.com>
> To: ltp-list@lists.sourceforge.net
> Sent: Friday, 20 June, 2014 3:41:06 PM
> Subject: [LTP] fstatfs02 issue on mips64
>
>
>
> Hi,
>
> I am testing mips64 with LTP. The problem is with fstatfs02.c file. The test
> case was failing in my particular arch. For debugging purpose I write the
> same code and executed.
>
> ret = fstatfs( -1,&buf );
>
> printf("Retrun value =%d, errornumber %d EBADF is %d %s FD %d pointer %p
> \n",ret,errno, EBADF,strerror(errno),-1,&buf);
>
> it was giving a output like
>
> Retrun value =- 1 , errornumber 9 EBADF is 9 Bad file descriptor FD -1
> pointer 0x120011130
>
> But when I executed LTP testcase with some debug print added
>
> TEST(fstatfs(TC[i].fd, (TC[i]).sbuf));
>
> if (TEST_RETURN != -1) {
>
> tst_resm(TFAIL, "call succeeded unexpectedly return %d %s FD %d, pointer sbuf
> %p ",TEST_RETURN,strerror(errno),TC[i].fd, TC[i].sbuf);
>
> I got a print like this
>
> fstatfs02 1 TFAIL : call succeeded unexpectedly return 1690729072 Success FD
> -1, pointer sbuf 0x12001ba30
>
> I feel like both are doing the same job… But when I am running it in LTP
> environment I am getting a return as 1690729072. I was not able to find any
> problem in TEST macro. Can anyone please help me out in debugging this.
What kernel/LTP release are you using?
You can try running good and bad case via strace. If parameters will be
correct and you still get strange numbers in strace output, it's likely a
kernel bug.
Regards,
Jan
L&T Technology Services Ltd
www.LntTechservices.com<http://www.lnttechservices.com/>
This Email may contain confidential or privileged information for the intended
recipient (s). If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
