Re: [LTP] clone01 -c 10 on x86

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Michal Simek (michal.simek@petalogix.com):
> Subrata Modak wrote:
> > On Mon, 2009-08-03 at 10:14 -0500, Serge E. Hallyn wrote: 
> >   
> >> Quoting Michal Simek (michal.simek@petalogix.com):
> >>     
> >>> Hi All,
> >>>
> >>> can you please to run clone01 syscall test on any x86 machine? I am
> >>> getting fault there when I run it 10 times for example.
> >>> The same problem I have on Microblaze.
> >>>
> >>>  ./clone01  -c 10
> >>> clone01     1  TPASS  :  clone() returned 22738
> >>> clone01     1  TPASS  :  clone() returned 22740
> >>> clone01     1  TPASS  :  clone() returned 22742
> >>> clone01     1  TPASS  :  clone() returned 22748
> >>> clone01     1  TPASS  :  clone() returned 22750
> >>> clone01     1  TPASS  :  clone() returned 22752
> >>> clone01     1  TPASS  :  clone() returned 22754
> >>> clone01     1  TFAIL  :  clone() returned 134919589, errno = 22755
> >>> [monstr@monstr clone]$ clone01     1  TPASS  :  clone() returned 22744
> >>> clone01     1  TPASS  :  clone() returned 22746
> >>>
> >>> Thanks,
> >>> Michal
> >>>       
> >> All right I don't have the patiente to wade through the parse_opts
> >> and usc_lib crap, but this is not a clone failure.  What appears to
> >> be happening is setup() at the top of clone01.c is calling
> >> lib/parse_opts.c:usc_global_setup_hook(), with STD_COPIES set to the
> >> count option you passed in.  That forks of 10 copies of the test.
> >> I don't know what happens with the actual loop then, but the reason
> >> you get the error for the last clone test is that one of those
> >> forked copies of clone01 (*not* one of the cloned children) exits,
> >> and wait() catches that one.  That is why wait() returned 22744,
> >> which isn't any of the cloned children.
> >>
> >> So one stupid way of fixing this without dealing with the convoluted
> >> setup junk would be to change the waitpid chunk of the code like so:
> >>     
> >
> > Yes, it fixes the issue.
> >   
> Yes, but as Serge wrote above his patch just cover different fault not
> solve it.

Although that depends on what we think the fault really is.  The reason
we were getting fail messages was that children were exiting which we
were (wrongly) not expecting.  Now, I don't understand why setup()
forks off N tasks, and it would probably be best to not do that.  But
in the end so long as we ignore when those tasks are reaped, it really
doesn't matter that there were extra children.  We are testing that clone(2)
succeeded now, which is what we really care about.

-serge

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list