Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: nils.carlson@ericsson.com (Nils Carlson)
Subject: [ltt-dev] [UST PATCH] TESTS: Add a delay at the start of the fork	test for a more uniform testing.
Date: Tue, 22 Feb 2011 16:54:39 +0100	[thread overview]
Message-ID: <4D63DC3F.9050406@ericsson.com> (raw)
In-Reply-To: <4D63CD7C.1020307@gmail.com>

Yannick Brosseau wrote:
> On 2011-02-22 03:28, Nils Carlson wrote:
>   
>> Yannick Brosseau wrote:
>>     
>>> Add a sleep to leave time for the ustconsumer thread to initialize
>>> correctly
>>> before the fork.
>>> Most of the time the consumer was not yet started at the time of the
>>> fork so
>>> a bunch of initializations were not done and the fork code path was not
>>> tested properly.
>>>
>>>   
>>>       
>> I'm afraid we're falling into a bit of a trap here. The trap is called
>> "fixing the test-case instead of fixing the code". It's quite typical
>>     
> No that's not the case here. I'm fixing the test case, so it shows us a
> problem that was occuring randomly before.
> With my "fix" to the test case, the test case will fail all the time and
> showing us the problem when we fork later. (Some application do it, so
> UST should not fail there)
>   
So you're saying that this causes the test case to fail all the time 
because now we leave time for things to properly initialise, while if we 
don't initialise things sometimes work?
I think I understand what you mean but I still don't agree. What about 
making sure somehow that we are fully initialized before we hit main()? 
In the case where we are tracing from startup using usttrace we should 
in fact be fully initialised before we allow the program to enter main.

If you don't think we should be fully initialized before entering main() 
please explain why.

/Nils
> I could duplicate the test case with one doing an early fork and one
> doing a late fork. I did not do it, because there was no problem to the
> early fork.
>
> The fix to the problem is my other email.
>
>   
>> for an application to fork right after startup. In fact, this is probably
>> by far the most common place where applications fork when going into a
>> daemon
>> mode. So we should probably focus on fixing the problem instead,
>> probably by
>> detecting that we are following forks with UST and if we are somehow
>> slowing
>> down the initialisation functions so that everything has started up
>> properly
>> by the time we enter main().
>>
>> /Nils
>>
>>     
>>> Signed-off-by: Yannick Brosseau <yannick.brosseau at gmail.com>
>>> ---
>>>  tests/fork/fork.c |    3 +++
>>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/tests/fork/fork.c b/tests/fork/fork.c
>>> index 5ce3d6d..a80518d 100644
>>> --- a/tests/fork/fork.c
>>> +++ b/tests/fork/fork.c
>>> @@ -34,6 +34,9 @@ int main(int argc, char **argv, char *env[])
>>>      printf("Fork test program, parent pid is %d\n", getpid());
>>>      trace_mark(ust, before_fork, MARK_NOARGS);
>>>  
>>> +    /* Sleep here to make sure the consumer is initialized before we
>>> fork */
>>> +    sleep(1);
>>> +
>>>      result = fork();
>>>      if(result == -1) {
>>>          perror("fork");
>>>   
>>>       
>
>   




  reply	other threads:[~2011-02-22 15:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-21 19:36 Yannick Brosseau
2011-02-22  8:28 ` Nils Carlson
2011-02-22 14:51   ` Yannick Brosseau
2011-02-22 15:54     ` Nils Carlson [this message]
2011-02-22 16:08       ` Yannick Brosseau
2011-02-23 15:45         ` Mathieu Desnoyers
2011-02-23  8:36 ` Nils Carlson

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=4D63DC3F.9050406@ericsson.com \
    --to=nils.carlson@ericsson.com \
    /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