----- Original Message -----
> From: "Ajoymon Joseph" <ajoy.jos...@lnttechservices.com>
> To: "Jan Stancek" <jstan...@redhat.com>
> Cc: ltp-list@lists.sourceforge.net
> Sent: Monday, 23 June, 2014 3:26:55 PM
> Subject: RE: [LTP] fstatfs02 issue on mips64
>
> 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.
It compiles the testcase with -D_FILE_OFFSET_BITS=64, which should have effect
only on 32 bit systems. [1]
1. Can you verify, that you can reproduce this issue with following program,
if you add compiler flag "-D_FILE_OFFSET_BITS=64"?
For example: gcc fstatfs.c -D_FILE_OFFSET_BITS=64
$ cat fstatfs.c
#include <sys/vfs.h>
#include <sys/types.h>
#include <sys/statfs.h>
#include <stdio.h>
int main()
{
fstatfs(-1, NULL);
return 0;
}
2. You mentioned mips64, is both kernel and userspace 64bit?
Once you compile for your test system, can you run "file" on the binary?
$ file ./a.out
3. If you run the binary via strace on test system, does it show calls to
fstatfs()?
4. If you can reproduce it with simple program above, can you compile it
statically,
for example: $ gcc fstatfs.c -D_FILE_OFFSET_BITS=64 -static
and have a look at disassembly of statfs function?
$ objdump -d ./a.out | less
You will need to use objdump from your toolchain.
5. What libc/uclibc library are you using on test system?
Regards,
Jan
[1]
http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#Feature-Test-Macros
>
> 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
