[LTP] fstatfs02 issue on mips64

[LTP] fstatfs02 issue on mips64

[Ajoymon Joseph]

[-- Attachment #1.1: Type: text/plain, Size: 1474 bytes --]

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.


thanks and regards
Ajoy


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.

[-- Attachment #1.2: Type: text/html, Size: 6655 bytes --]

[-- Attachment #2: Type: text/plain, Size: 370 bytes --]

------------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] fstatfs02 issue on mips64

[Jan Stancek]

----- Original Message -----
> From: "Ajoymon Joseph" <AJOY.JOSEPH@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

------------------------------------------------------------------------------
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

Re: [LTP] fstatfs02 issue on mips64

[chrubis]

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.

Hmm, that looks like the return value from fstatfs() gets corrupted
before it gets to the if () below. However the code of the TEST() macro
looks too simple for that to happen.

The lines gets expaned (with compiler -E) to:

   do { (*__errno_location ()) = 0; TEST_RETURN = fstatfs(TC[i].fd, TC[i].sbuf); TEST_ERRNO = (*__errno_location ()); } while (0);

   if (TEST_RETURN != -1) {
    tst_resm(1, "call succeeded unexpectedly");
    continue;
   }

Which, as far as I can see, looks correct.

Assuming that the fstatfs() really returns -1 here (have you tried
strace on the testcase?) the only problem I can think of is that the
code gets miscompiled and the value is corrupted in the TEST_RETURN =
fstatfs(TC[i].fd, TC[i].sbuf) part. I would check the disassembly to
make sure that it does what is expected.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
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

Re: [LTP] fstatfs02 issue on mips64

[Ajoymon Joseph]

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:jstancek@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.JOSEPH@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

Re: [LTP] fstatfs02 issue on mips64

[chrubis]

Hi!
> I am not seeing fstatfs call itself when comparing the system call. I
> hope this is the reason?

That is strange but I would not call this to be the reason for the test
fail.

> 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.

The difference is that the _64 testcases are compiled with
-D_FILE_OFFSET_BITS=64 so it's possible that there is something wrong
with large file support on your platform.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
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

Re: [LTP] fstatfs02 issue on mips64

[Jan Stancek]

----- Original Message -----
> From: "Ajoymon Joseph" <AJOY.JOSEPH@lnttechservices.com>
> To: "Jan Stancek" <jstancek@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:jstancek@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.JOSEPH@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

Re: [LTP] fstatfs02 issue on mips64

[chrubis]

Hi!
> statfs  is not there in strace output. Can you please tell me what can be the reason for strace not showing those functions?

No idea :(

Without carefull analysis this can range from missing implementation in
strace to bugs in strace implementation.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
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

Re: [LTP] fstatfs02 issue on mips64

[chrubis]

Hi!
> > statfs  is not there in strace output. Can you please tell me what can be the reason for strace not showing those functions?
> 
> No idea :(
> 
> Without carefull analysis this can range from missing implementation in
> strace to bugs in strace implementation.

Or could even mean that your libc fails to call the syscall and returns
bogus return value instead...

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
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

Re: [LTP] fstatfs02 issue on mips64

[Ajoymon Joseph]

Hi jan,

I was able to reproduce the issue with sample program.

Program was:
  1 #include <sys/vfs.h>
  2 #include <sys/types.h>
  3 #include <sys/statfs.h>
  4 #include <stdio.h>
  5
  6 int main()
  7 {
  8         int ret;
  9         ret = fstatfs(-1, NULL);
 10         printf("return fstatfs %d\n ",ret);
 11         return 0;
 12 }
 13

Compiled using the following command
gcc  fstatpgm1.c -D_FILE_OFFSET_BITS=64 -march=octeon2 -mabi=64 -msoft-float -Wall -Wextra -fno-strict-aliasing -O2 -o out1 -mabi=64 -msoft-float -L/usr/lib64
those extra flags and libraries are required for the test system. A warning was given
fstatpgm1.c: In function 'main':
fstatpgm1.c:9: warning: null argument where non-null required (argument 2)



2. file out1
out1: ELF 64-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), for GNU/Linux 2.6.9, statically linked, not stripped

output uname -a
SMP PREEMPT mips64 GNU/Linux

3. I ran the binary using strace. It is not showing fstafs

$ strace ./out1
execve("./out1", ["./out1"], [/* 15 vars */]) = 0
brk(0)                                  = 0x120011000
uname({sys="Linux", node="CPU1", ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x556219c000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = -1 ENOENT (No such file or directory)
open("/lib64/tls/octeon2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/lib64/tls/octeon2", 0xffffc3e5e0) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libc.so.6", O_RDONLY)  = -1 ENOENT (No such file or directory)
stat("/lib64/tls", 0xffffc3e5e0)        = -1 ENOENT (No such file or directory)
open("/lib64/octeon2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/lib64/octeon2", 0xffffc3e5e0)    = -1 ENOENT (No such file or directory)
open("/lib64/libc.so.6", O_RDONLY)      = 3
read(3, "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\0\0\0\3b\250"..., 832) = 832
lseek(3, 60728, SEEK_SET)               = 60728
read(3, "\0\0\0\4\0\0\0\20\0\0\0\1GNU\0\0\0\0\0\0\0\0\2\0\0\0\6\0\0\0\t", 32) = 32
fstat(3, {st_mode=S_IFREG|0755, st_size=1693440, ...}) = 0
mmap(NULL, 1679632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x55621ae000
mprotect(0x5562323000, 61440, PROT_NONE) = 0
mmap(0x5562332000, 73728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x174000) = 0x5562332000
mmap(0x5562344000, 16656, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x5562344000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x556219d000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x556219e000
set_thread_area(0x55621a4b90)           = 0
mprotect(0x5562332000, 57344, PROT_READ) = 0
mprotect(0x55621ab000, 4096, PROT_READ) = 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) = 0x5562349000
write(1, "return fstatfs 1646910064\n", 26return fstatfs 1646910064
) = 26
write(1, " ", 1 )                        = 1
exit_group(0)                           = ?

4. The issue was reproducible. So I build it static
gcc -g fstatpgm1.c -D_FILE_OFFSET_BITS=64 -march=octeon2 -mabi=64 -msoft-float -Wall -Wextra -fno-strict-aliasing -O2 -o out1 -mabi=64 -msoft-float -L/usr/lib64 -static

objdump follows.

main():
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:7
   120003b50:   67bdfff0        daddiu  sp,sp,-16
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:9
   120003b54:   2404ffff        li      a0,-1
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:7
   120003b58:   ffbc0000        sd      gp,0(sp)
   120003b5c:   3c1c000b        lui     gp,0xb
   120003b60:   0399e02d        daddu   gp,gp,t9
   120003b64:   ffbf0008        sd      ra,8(sp)
   120003b68:   679c0320        daddiu  gp,gp,800
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:9
   120003b6c:   df998708        ld      t9,-30968(gp)
   120003b70:   0320f809        jalr    t9
   120003b74:   0000282d        move    a1,zero
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:10
   120003b78:   df848048        ld      a0,-32696(gp)
   120003b7c:   df999530        ld      t9,-27344(gp)
   120003b80:   0040282d        move    a1,v0
   120003b84:   0320f809        jalr    t9
   120003b88:   6484ab78        daddiu  a0,a0,-21640
/user/ajoy.joseph/LTP/sample_app/fstatpgm1.c:12
   120003b8c:   dfbf0008        ld      ra,8(sp)
   120003b90:   dfbc0000        ld      gp,0(sp)
   120003b94:   0000102d        move    v0,zero
   120003b98:   03e00008        jr      ra
   120003b9c:   67bd0010        daddiu  sp,sp,16
__libc_start_main():
   120003ba0:   67bdfed0        daddiu  sp,sp,-304

5. I am using
        libc.so.6 => /lib64/libc.so.6
        /lib64/ld.so.1
        /lib64/libc.so.6 -> libc-2.11.1.so
        gcc version 4.4.1

I don’t understand objdump output much. Sorry to tell that. How to analyze it?

Regards
Ajoy

-----Original Message-----
From: Jan Stancek [mailto:jstancek@redhat.com]
Sent: Monday, June 23, 2014 8:18 PM
To: Ajoymon Joseph
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] fstatfs02 issue on mips64




----- Original Message -----
> From: "Ajoymon Joseph" <AJOY.JOSEPH@lnttechservices.com>
> To: "Jan Stancek" <jstancek@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:jstancek@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.JOSEPH@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.
>
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.
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] fstatfs02 issue on mips64

[Jan Stancek]

----- Original Message -----
> From: "Ajoymon Joseph" <AJOY.JOSEPH@lnttechservices.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp-list@lists.sourceforge.net
> Sent: Tuesday, 24 June, 2014 8:35:45 AM
> Subject: RE: [LTP] fstatfs02 issue on mips64
> 
> Hi jan,
> 
> I was able to reproduce the issue with sample program.
> 
> Program was:
>   1 #include <sys/vfs.h>
>   2 #include <sys/types.h>
>   3 #include <sys/statfs.h>
>   4 #include <stdio.h>
>   5
>   6 int main()
>   7 {
>   8         int ret;
>   9         ret = fstatfs(-1, NULL);
>  10         printf("return fstatfs %d\n ",ret);
>  11         return 0;
>  12 }
>  13
> 
> Compiled using the following command
> gcc  fstatpgm1.c -D_FILE_OFFSET_BITS=64 -march=octeon2 -mabi=64 -msoft-float
> -Wall -Wextra -fno-strict-aliasing -O2 -o out1 -mabi=64 -msoft-float
> -L/usr/lib64
> those extra flags and libraries are required for the test system. A warning
> was given
> fstatpgm1.c: In function 'main':
> fstatpgm1.c:9: warning: null argument where non-null required (argument 2)
> 
> 
> 
> 2. file out1
> out1: ELF 64-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), for
> GNU/Linux 2.6.9, statically linked, not stripped

According to [1], e_flags seems to be EF_MIPS_ARCH_32R2, meaning:
"This file will run on a machine with the architecture describe for Mips32 Revision 2"
Which looks a bit suspicious, given that this is supposed to be 64bit.

I'm assuming if you compile following:
	printf("%d\n", sizeof(struct statfs)); 
with and without "-D_FILE_OFFSET_BITS=64" it is going to give you different numbers.

Just a wild guess, can you try to compile/run reproducer with "-march=mips64r2" instead of "-march=octeon2" ?

[1] https://dmz-portal.mips.com/wiki/MIPS_ELF_header_definitions

> 
> output uname -a
> SMP PREEMPT mips64 GNU/Linux
> 
> 3. I ran the binary using strace. It is not showing fstafs
> 
> 
> 4. The issue was reproducible. So I build it static
> gcc -g fstatpgm1.c -D_FILE_OFFSET_BITS=64 -march=octeon2 -mabi=64
> -msoft-float -Wall -Wextra -fno-strict-aliasing -O2 -o out1 -mabi=64
> -msoft-float -L/usr/lib64 -static
> 
> objdump follows.

Was that whole objdump output? It didn't show fstatfs() function,
just main() and __libc_start_main().

> 
> 5. I am using
>         libc.so.6 => /lib64/libc.so.6
>         /lib64/ld.so.1
>         /lib64/libc.so.6 -> libc-2.11.1.so
>         gcc version 4.4.1

I'm assuming this is from test system.

Anyway, we confirmed, that it's not a bug in LTP. You were able to reproduce it
with sample program above, which is not including/linking LTP. I suggest you
also reach out to your BSP vendor and ask him about this behaviour.

Regards,
Jan

> 
> I don’t understand objdump output much. Sorry to tell that. How to analyze
> it?
> 
> Regards
> Ajoy
> 
> -----Original Message-----
> From: Jan Stancek [mailto:jstancek@redhat.com]
> Sent: Monday, June 23, 2014 8:18 PM
> To: Ajoymon Joseph
> Cc: ltp-list@lists.sourceforge.net
> Subject: Re: [LTP] fstatfs02 issue on mips64
> 
> 
> 
> 
> ----- Original Message -----
> > From: "Ajoymon Joseph" <AJOY.JOSEPH@lnttechservices.com>
> > To: "Jan Stancek" <jstancek@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:jstancek@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.JOSEPH@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.
> >
> 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.
> 

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list