This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/12711] New: __bb_exit_func() arc profiling errors


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12711

           Summary: __bb_exit_func() arc profiling errors
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hp at redhat dot com
                CC: gcc-bugs at gcc dot gnu dot org

The immediate bug I'm encountering is that __bb_exit_func() will print
"arc profiling: failed to open output file (null)" over and over.
I'm attaching a program that when built with -fprofile-arcs -ftest-coverage 
will show this behavior.

This is because of the code:
       if (error || !merging)
	ptr->filename = 0;

The !merging case sets filename to 0, then on subsequent iterations the code
doesn't check ptr->filename != 0 and passes the null pointer to fopen()
resulting in EFAULT.

However, other possible issues:

 1. I don't understand why further writes to the .da file are disabled 
    if !merging. If someone could explain this I could maybe find a 
    better fix for the problem than only adding an if (!ptr->filename)
    check.

 2. It seems to me that the fcntl() locking is broken; if the lock is held, 
    fcntl() will fail and return EACCES or EAGAIN, and in that case the 
    code just continues on to write to the file, as far as I can tell.
    I have a patch that will repeatedly sleep and retry the lock if 
    the lock fails.

 3. None of the error messages print strerror, I have a patch for this also.

In any case, some guidance on the correct fix for the !merging case and what I
am missing about the file locking issue would be welcome.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]