Hi Namhyung,

于 2014/2/26 16:03, Namhyung Kim 写道:
> Hi xiakaixu,
> 
>> 于 2014/2/19 9:48, xiakaixu 写道:
>>> Hi all,
>>>
>>> There is a bug found in my work when running "perf record". The basic 
>>> information
>>> is here. As we know, perf record is a parent process and the programme 
>>> traced is
>>> a child process when running "perf record". Sometimes the child process 
>>> become
>>> zombie state and disappear until the parent process is killed. The bug 
>>> stays in linux/
>>> tools/perf/builtin-record.c.
>>> *********************************************************************
>>> static int __cmd_record(struct perf_record *rec, int argc, const char 
>>> **argv)
>>>     ......
>>>     if (hits == rec->samples) {
>>>                          if (done)
>>>                                  break;
>>>                          err = poll(evsel_list->pollfd, evsel_list->nr_fds, 
>>> -1);
>>>                          waking++;
>>>                  }
>>>     ......
>>> *********************************************************************
>>> The parent process still call the function
>>> poll(evsel_list->pollfd, evsel_list->nr_fds, -1) when the child process has 
>>> exited
>>> already, which caused a zombie process.
>>>
>>> May I have your opinion ?
>>> Waiting for your reply!
> 
> Do you have a real bug report based on this?
yeah, of course we have it, I'll be glad to provide it if necessary.
> 
> AFAIK perf record installed a signal handler for SIGCHLD so it'll set
> the 'done' variable when child exits and then break the loop.
yes, you are right. Though the 'done' varible will be set when child exits,
there is time gap between "if(done)" statement and "poll(...)" function.
The 'done' variable won't be judge when child exits in this time gap.
You know this time gap is instruction level, so this bug is small probability.
My solution is adding a while(...) statement outside poll(...) function.
>
> Thanks,
> Namhyung
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to