This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: gcov can't collect data when process is executed by systemctl start but it can when executed by ./process
On 2017-07-31一的 06:05 -0400, Xiaoli Feng wrote:
>
> ----- Original Message -----
> > From: "Mason" <slash.tmp@free.fr>
> > To: "Xiaoli Feng" <xifeng@redhat.com>
> > Cc: "GCC help" <gcc-help@gcc.gnu.org>
> > Sent: Monday, July 31, 2017 5:12:38 PM
> > Subject: Re: gcov can't collect data when process is executed by systemctl start but it can when executed by
> > ./process
> >
> > On 31/07/2017 10:57, Xiaoli Feng wrote:
> > > Hello,
> > >
> > > Sorry to noise you. But I don't know how to fixed this issue. The gcov
> > > can
> > > collect code coverage data if the process is executed in shell. But when
> > > the process is start by systemd service. The *.gcda can't be generated. I
> > > google
> > > many info. But there is no solution. So I only send mail to ask for your
> > > help.
> > > Does any one know what's happen? And where to find the gcov error
> > > message?
By default systemd terminates a service by sending SIGTERM.
(See systemd.kill(5).) If your service doesn't handle it and will just be
killed, it won't produce .gcda file.
Your service should handle SIGTERM and terminate cleanly, like:
void handler(int signum)
{
/* notify the operator that the service has receive SIGTERM
and clean up (close file descriptors, etc). */
exit(0);
}
int main(int argc, char **argv)
{
signal(handler, SIGTERM);
/* do service */
}
By using exit(), the functions registered by atexit() and on_exit() would be
called. GCC registers one atexit function to produce .gcda file.
Even if without gcov, it's recommended to catch SIGTERM and terminate your
service cleanly.
> > > If I send the wrong email address. Sorry about that.
This is the correct mail list to request help using GCC. And I think maybe
we should document this issue somewhere (in 'info gcc' or GCC wiki).
> > Could it be that when the process is run by systemd, it runs
> > under a different user id, one which is not allowed to write
> > to the directory?
>
> I don't think so. I run "ps -aux". And it shows the process's USER is root.
> Do you know if there is a method to check the error info when generate *.gcda?
> And if it is under a different user. How could I change the writing directory
> location?
If I am correct, there should be no error info available since the process was
killed suddenly and had no chance to print out something.
> Thanks Mason for your reply.
>
> >
> > Regards.
> >
--
Xi Ruoyao <ryxi@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University