> -----Original Message-----
> From: Douglas Bailey [mailto:community-noreply@qnx.com] 
> Sent: February 2, 2010 11:00 AM
> To: ostech-core_os
> Subject: question about regression test case proc_pr10388
> 
> 
> I've got a question for folks a little more familiar with 
> process control and signals than I...
> 
> Please take a look at the test case deunit/proc_pr10388.c.  
> We've recently been seeing occasional fails from it, with the 
> following
> symptoms:
> 
> START: /tmp/proc_pr10388, pid 73007116
> POINT: file regress/deunit/proc_pr10388.c, line 84 Get status 
> of procmgr_daemon process
> NOTE:  file regress/deunit/proc_pr10388.c, line 45 SIGCHLD 
> pid=73011213
> FAIL:  file regress/deunit/proc_pr10388.c, line 122 child status was 1
> STOP:  /tmp/proc_pr10388, pid 73007116 
> point=1,pass=0,fail=1,xpass=0,xfail=0,unres=0
> 
> I'm thinking this might be a testcase problem.  The testcase 
> has always been successful until recently, but it looks like 
> it might just be a shift in timing that is causing the 
> testcase to fail instead of a real problem with the system.
> 
> The testcase forks a child thread that does a procmgr_daemon 
> with one exit code (which should cause the SIGCHLD to be 
> delivered to the parent), then kills itself with a 
> raise(SIGILL).  The parent process has set up a SIGCHLD 
> handler.  When it receives the SIGCHLD it delays a little by 
> invoking times() in order to let the child do the raise(), 
> then does a waitpid on the child.  The parent expects to see 
> that the child died with SIGILL.
> 
> I think that it is a bad idea to assume that the times() call 
> is sufficient to allow the child to do the raise().


If both are running at the same priority, it will ensure that the child
is given at least one timeslice(since the parent goes to the end of the
ready queue).  However, if the child blocks, or needs more than one
timeslice, this isn't going to guarentee the desired behaviour.  I would
suggest making the parent drop its priority by 1, right after the
fork().


>  If the 
> parent does the waitpid before the raise call, it will return 
> from waitpid with a status indicating WIFEXITED and the value 
> given to procmgr_daemon -- and this is what the failed test 
> case runs are showing.

I thought this was the ONLY thing it could ever return?  After the
procmgr_daemon(), the child is in process group 1 with pid 1 as it's
parent, so the original parent shouldn't ever see the results of the
raise().


> 
> So, I believe it's a test case problem.  The times() call is 
> not sufficient to ensure that the child has done the raise() 
> before the parent process calls waitpid...
> 
> Does that sound correct?
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post46393
> 
>