On Thu, Oct 15, 2009 at 5:43 AM, Garrett Cooper <[email protected]> wrote:
> On Thu, Oct 15, 2009 at 1:44 AM, Chandru <[email protected]> wrote:
>> On Thursday 15 October 2009 06:55:29 Garrett Cooper wrote:
>>> Just curious -- was the issue seen at the following point in the code
>>> previously?
>>>
>>> 361 TEST(sys_ret = syscall(__NR_ppoll, p_fds, nfds, p_ts,
>>> p_sigmask, sigsetsize)); /* <-- Blocks here indefinitely */
>>> 362 sys_errno = errno;
>>> 363 if (sys_ret <= 0 || tc->ret < 0)
>>> 364 goto TEST_END;
>>> 365
>>> 366 cmp_ok = fds[0].revents == tc->expect_revents;
>>>
>>> I've seen this issue 1 out of the 8 or 9 times I've run this test.
>>
>> Nope, without the patch we only see case00 completing and the test exits
>> while in the middle of case01
>>
>> # ./ppoll01
>> ppoll01 0 TINFO : (case00) START
>> EXPECT: return value(ret)=(N >= 0) errno=0 (Success)
>> RESULT: return value(ret)= 1 errno=0 (Success)
>> ppoll01 0 TINFO : (case00) END => OK
>> ppoll01 0 TINFO : (case01) START
>> #
>>
>>
>> With the patch we see the output as follows...
>>
>> # ./ppoll01
>> ppoll01 0 TINFO : (case00) START
>> EXPECT: return value(ret)=(N >= 0) errno=0 (Success)
>> RESULT: return value(ret)= 1 errno=0 (Success)
>> ppoll01 0 TINFO : (case00) END => OK
>> ppoll01 0 TINFO : (case01) START
>> EXPECT: return value(ret)=(N >= 0) errno=0 (Success)
>> RESULT: return value(ret)= 0 errno=0 (Success)
>> ppoll01 0 TINFO : (case01) END => OK
>> ppoll01 0 TINFO : (case02) START
>> EXPECT: return value(ret)=(N >= 0) errno=0 (Success)
>> RESULT: return value(ret)= 0 errno=0 (Success)
>> ppoll01 0 TINFO : (case02) END => OK
>> ppoll01 0 TINFO : (case03) START
>> EXPECT: return value(ret)=(N >= 0) errno=0 (Success)
>> RESULT: return value(ret)= 1 errno=0 (Success)
>> ppoll01 0 TINFO : (case03) END => OK
>> ppoll01 0 TINFO : (case04) START
>> EXPECT: return value(ret)=-1 errno=4 (Interrupted system call)
>> RESULT: return value(ret)=-1 errno=4 (Interrupted system call)
>> ppoll01 0 TINFO : (case04) END => OK
>> ppoll01 0 TINFO : (case05) START
>> EXPECT: return value(ret)=-1 errno=4 (Interrupted system call)
>> RESULT: return value(ret)=-1 errno=4 (Interrupted system call)
>> ppoll01 0 TINFO : (case05) END => OK
>> ppoll01 0 TINFO : (case06) START
>> EXPECT: return value(ret)=-1 errno=22 (Invalid argument)
>> RESULT: return value(ret)=-1 errno=22 (Invalid argument)
>> ppoll01 0 TINFO : (case06) END => OK
>> ppoll01 0 TINFO : (case07) START
>> EXPECT: return value(ret)=-1 errno=14 (Bad address)
>> RESULT: return value(ret)=-1 errno=14 (Bad address)
>> ppoll01 0 TINFO : (case07) END => OK
>> ppoll01 1 TPASS : ppoll01 call succeeded
>
> Interesting. The cause may be the same, but the effect may be
> different, as this is blocking with this section of the test:
>
> case MINUS_NSEC:
> ts.tv_sec = 0;
> ts.tv_nsec = -1;
> p_ts = &ts;
> break;
>
> Which is fine, but depending on whether or not a previous testcase
> fails with EOK and a return code of 0. Example:
Sorry -- incomplete thought.
Depending on whether or not it fails with a return code of 0 -- it may
be in our best interest to retry a finite number of times, then give
up and cordon off that testcase so that it can't run and thus block
indefinitely.
> #define _GNU_SOURCE
> #include <signal.h>
> #include <poll.h>
> #include <errno.h>
> #include <string.h>
>
> int main (void) {
>
> struct pollfd fds;
> struct timespec timeout;
> sigset_t sigmask;
>
> sigemptyset(&sigmask);
>
> timeout.tv_sec = 0;
> timeout.tv_nsec = 5e8; /* .5 sec */
>
> if (ppoll(&fds, 1, &timeout, &sigmask) <= 0) {
> perror("ppoll");
> return 0;
> }
> return 1;
> }
>
> gcoo...@orangebox ~ $ ./ppoll_test
> ppoll: Success
>
> The manpage doesn't say that it shouldn't set errno to ETIME, etc,
> so this is a legitimate return value (despite the fact that the
> testcase fails claiming that the subtestcase failed and the call
> succeeded, IIRC -- or maybe it was another test...).
> I'll definitely keep my eyes peeled for this particular issue
> though in the future.
Thanks,
-Garrett
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
