public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Mason <slash.tmp@free.fr>
To: ltp@lists.linux.it
Subject: [LTP] Issue with the reporting of failed tests
Date: Mon, 25 Apr 2016 13:40:22 +0200	[thread overview]
Message-ID: <571E0226.3020104@free.fr> (raw)
In-Reply-To: <571DCF8D.30306@free.fr>

On 25/04/2016 10:04, Mason wrote:
> On 22/04/2016 15:29, Mason wrote:
>> On 21/04/2016 19:02, Mason wrote:
>>> On 21/04/2016 17:42, Mason wrote:
>>>> On 21/04/2016 17:30, Cyril Hrubis wrote:
>>>>> Hi!
>>>>>> Calling fflush does appear to solve the problem:
>>>>>>
>>>>>> # grep -c FAIL result-log.5160
>>>>>> 38
>>>>>>
>>>>>> # wc -l result-failed.5160
>>>>>> 38 result-failed.5160
>>>>>>
>>>>>> Does this mean no one ever reads FAILCMDFILE?!
>>>>>
>>>>> Just to have complete image here. I've discussed this a bit more at #ltp
>>>>> irc channel and the reason why we do not see this bug often is that the
>>>>> exec() that is done by the child after pan forks must fail (for example
>>>>> since bash is missing) then the code proceeds to exit(errno) line which
>>>>> flushes the buffers on open files...
>>>>
>>>> Note: in my latest LTP run, I disabled memory overcommit, and pan
>>>> failed to launch several tests:
>>>>
>>>> pan(5163): fork failed (tag proc01).  errno:12  Cannot allocate memory
>>>> pan(5163): fork failed (tag fs_racer).  errno:12  Cannot allocate memory
>>>> pan(5163): fork failed (tag quota_remount_test01).  errno:12  Cannot allocate memory
>>>> pan(5163): fork failed (tag isofs).  errno:12  Cannot allocate memory
>>>> pan(5163): fork failed (tag fs_perms01).  errno:12  Cannot allocate memory
>>>> [747 similar lines]
>>>>
>>>> /tmp is a ramfs. Maybe something fills it up...
>>>
>>> With overcommit enabled, all tests complete, but some problems remain:
>>>
>>> $ grep -c FAIL result-log.24583 
>>> 85
>>>
>>> $ wc -l result-failed.24583
>>> 157 result-failed.24583
>>>
>>> $ sort result-failed.24583 | uniq | wc -l
>>> 83
>>>
>>> I'm confused as to what else is causing this...
>>
>> I am now testing yet another LTP run with the following patch applied.
> 
> There still is an inconsistency between result-log and result-failed.
> 
> $ grep -c FAIL result-log.30032
> 119
> 
> $ wc -l result-failed.30032
> 319 result-failed.30032
> 
> $ sort result-failed.30032 | uniq | wc -l
> 117
> 
> Either I didn't use the modified ltp-pan binary, or the change has no effect.
> (I will print something to stderr to make sure.)

I do see an improvement now: no more duplicates. However, it seems
2 tests are missing from result-failed: aio01, aio02.

$ grep -c FAIL result-log.1125
27

$ wc -l result-failed.1125
25 result-failed.1125

Regards.

  reply	other threads:[~2016-04-25 11:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-21 13:25 [LTP] Issue with the reporting of failed tests Mason
2016-04-21 14:47 ` Mason
2016-04-21 15:30   ` Cyril Hrubis
2016-04-21 15:42     ` Mason
2016-04-21 17:02       ` Mason
2016-04-21 18:59         ` Mason
2016-04-22 13:29         ` Mason
2016-04-25  8:04           ` Mason
2016-04-25 11:40             ` Mason [this message]
2016-04-25 12:46               ` Mason
2016-04-25 13:31                 ` Cyril Hrubis
2016-04-25 14:24                   ` Mason
2016-04-25 14:46                     ` Cyril Hrubis
2016-04-26  9:51                       ` [LTP] getrusage04 on ARM fails sometimes Sebastian Frias
2016-04-25 13:04               ` [LTP] Issue with the reporting of failed tests Cyril Hrubis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=571E0226.3020104@free.fr \
    --to=slash.tmp@free.fr \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox