[lsb-discuss] Unresolved result in LSB test

Andrew Josey ajosey at opengroup.org
Wed Feb 1 17:27:27 UTC 2012


hi Stew, all

I asked my engineers who maintain these tests, and the response is below, note that we refer to a variable SPEEDFACTOR that can impact the tests, I'm not sure how you set that within the LSB tests these days...
regards
Andrew

On 1 Feb 2012, at 17:23, Stew Benedict wrote:

> While it's quite possible the tests are bad (some might say it's always the tests' fault), I'm not finding any reference to either of these 2 tests in our bugzilla or problem database, nor do they seem familiar to me. I do regular testing on a number of distributions and usually open bugs on things I see fail with any consistency. Is there a specific architecture involved?
> 
> The best thing to do would be to open a bug in our bugzilla, which can then be referenced by the problem_db and used as a talking point if you wanted to request a waiver of these tests for certification.
> 
> -- 
> Stew Benedict


>> I have run LSB distribution checker for certification. In running core tests (4.0.6-1), I received two 'unresolved' results: 
>> 
>> /tset/ANSI.os/genuts/abort/T.abort 11
>> Message from the test:
>> child process still active 15 seconds after calling abort()
>> unexpected signal 15 (SIGTERM) received
>> 
>> /tset/POSIX.os/devclass/i_ctty/T.i_ctty 6
>> Message from the test:
>> child process timed out
>> 
>> I checked test code and found the two tests have similar process that lead to unresolved results. A brief process of the test are listed below:
>> 
>> Using fork() to create a new process;
>> In child process:
>> 1) Create two pseudo-terminal. For convenience, called tty and loop, master/slave of tty call PTM1/PTS1, master/slave of loop call  PTM2/PTS2. The controlling terminal is tty. VINTR is set to 0x03 in tty side, while VINTR is set to vdisable in loop side;
>> 2) Connect two master pty's by forking two child process: child-1 copy the output of PTM1 to PTM2's input, and child-2 copy the output of PTM2 to PTM1's input;
>> 3) Set the signal handler sig_catch() to handle the SIGINT;
>> 4) Write 0x03 to PTS2;
>> 5) pause();
>> ...
>> 
>> Test program may expect to received SIGINT that cause pause() function return. But I think the program does not guarantee that. When writing character 0x03 to PTS2, this character will be sent to PTM2, then copied to PTM1 by child-2. Then tty will generate a SIGINT signal and send to all processes in the foreground process group because it is the controlling terminal and its VINTR is set to 0x03. The character will be discarded after processing and no longer copied to PTM2 again. 
>> 
>> There is not any measure to ensure pause function has been executed when the SIGINT signal is sent.

This is true.

> So the pause function unable to return and cause a timeout. 

The process calling pause() sets an alarm before calling it.
If the SIGINT arrives before pause() is called, the alarm
signal will interrupt the pause().

Looking at the timings, in abort 11 the parent waits for 15
seconds and the child sleeps for 4 seconds then has an
alarm time of 7 seconds on the pause().  This leaves 4 seconds
for the child to complete its other processing.  In i_ctty 6
the parent waits for 19 seconds and the child timings are
the same as abort 11, so there are 8 seconds for the child
to complete its other processing.

If the system under test is heavily loaded, that might account
for 8 seconds not being long enough.  It may be worth building with
a larger value of SPEEDFACTOR to see if that helps.  (Or ensure the
tests are run when the system is lightly loaded.)


--------
Andrew Josey                 The Open Group
Director, Standards          Apex Plaza, Forbury Road
Email: a.josey at opengroup.org Reading,Berks.RG1 1AX,England
Tel:+44 118 9023044          US fax:  +1 415 276 3760
Mobile:+44 774 015 5794      UK fax:  +44 870 131 0418

TOGAF and UNIX are registered trademarks of The Open Group in the US and other countries.

















More information about the lsb-discuss mailing list