----- "Caspar Zhang" <[email protected]> wrote: > ----- "Garrett Cooper" <[email protected]> wrote: > > > On Tue, Sep 7, 2010 at 8:13 AM, Caspar Zhang <[email protected]> > > wrote: > > > > > > ----- "Garrett Cooper" <[email protected]> wrote: > > > > > >> On Tue, Sep 7, 2010 at 5:18 AM, Caspar Zhang <[email protected]> > > >> wrote: > > >> > Hi all, > > >> > When I run testcases/network/nfs/nfsstress/ test, I found > > sometimes > > >> the > > >> > test failed due to buffered I/O, in detail, for example, there > > are > > >> the following > > >> > lines in make_tree.c : > > >> > > > >> > 544 numchar[0] = sprintf(prog_buf, > > >> > 545 "main()\n{\n\t printf(\"hello > > world\");\n}\n"); > > >> > > > >> > sometimes the generated .c file will be: > > >> > ^...@ain() // <- strange ASCII char '^@' appears instead of 'm' > > >> > { > > >> > printf("hello world"); > > >> > } > > >> > > > >> > And running with this .c file will cause error. > > >> > > > >> > That is to say, string 'prog_buf' gets a mistake during > sprintf. > > And > > >> there're > > >> > somewhere else using buffered I/O in this test as well. Do we > > have > > >> an > > >> > unbuffered solution to this test? > > >> > > >> That seems a bit odd. Is the NFS mount/server TCP or UDP? > > > > > > Hi Garrett, it's UDP. > > > > Ok. Something else that might be good to note is whether or not > > it's v2, v3, or v4 on the client and server side. > > Could you please try with TCP and see whether or not the issue > > persists? I'm just curious if it's a potentially real issue with > NFS > > code in the kernel, random networking infrastructure issues, etc. > > Thanks, > > Hi Garrett, sorry for late reply. I tried all combinations of TCP/UDP > > and v2/v3/v4 but the error still existed. I wrote a workaround patch > and re-tested with the combinations above, the issue seemed to be > solved. > > This patch have 2 fixes: > > a) extend malloc length from 1024 to 2048. If we keep both default dir > num > and file num as 100, the string length of dirname/filename length will > be > easily > 1024 bytes. This will cause string buffer overflow and the > main.c > may be filled with such wrong chars: > '19123.97/19123.98/19123.99/19123.99.0.cmain()...' > > b) add tmpdirname var in some sprintf sentences. According the man > page of > sprintf: > > NOTES > Some programs imprudently rely on code such as the following > sprintf(buf, "%s some further text", buf); > to append text to buf. However, the standards explicitly note > that the results are undefined if source and destination buffers > overlap when calling sprintf(), snprintf(), vsprintf(), and > vsnprintf(). Depending on the version of gcc(1) used, and the > compiler options employed, calls such as the above will not produce > the expected results. > > Signed-off-by: Caspar Zhang <[email protected]>
Hi all, any comments on this? Patch was tested under RHEL5 and RHEL6 and passed. Thanks, Caspar > > Thanks, > Caspar > > -- > Quality Assurance Associate (Kernel) in > Red Hat Software (Beijing) Co., R&D Branch > > TEL: +86-10-62608150 > WEB: http://www.redhat.com/ -- Quality Assurance Associate (Kernel) in Red Hat Software (Beijing) Co., R&D Branch TEL: +86-10-62608150 WEB: http://www.redhat.com/ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
