This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 107096 - arc profiling tries to open null output file
arc profiling tries to open null output file
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-14 19:09 EDT by Havoc Pennington
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-21 14:41:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
test case, compile with -fprofile-arcs -ftest-coverage (481 bytes, text/plain)
2003-10-21 01:46 EDT, Havoc Pennington
no flags Details

  None (edit)
Description Havoc Pennington 2003-10-14 19:09:24 EDT
This happens in dbus make check, but I don't have a small test case yet. I
looked at the gcc code some but couldn't find where the struct bb -> filename field 
is supposed to get filled in.

Error is: "arc profiling: Can't open output file (null)."
in libgcc2.c:1360 (__bb_exit_func)
Comment 1 Havoc Pennington 2003-10-14 20:27:34 EDT
A possible clue is that running the test suite is generating 
e.g. dbus/.libs/dbus-connection.da instead of dbus/dbus-connection.da
(.da files have moved to .libs vs. gcc 3.2 they were alongside the source files)
Comment 2 Havoc Pennington 2003-10-14 23:15:44 EDT
Or in fact the .bbg files are *both* in the srcdir and in .libs, for only some
of my subdirectories, and the .da files are *only* in .libs for those directories.
The .da files are in the srcdir for other directories.

This is probably unrelated to the bug.

Comment 3 Havoc Pennington 2003-10-15 19:25:52 EDT
The "failed to open (null)" is probably because on any error the code in
__bb_exit_func sets filename = NULL, so will then proceed to fail to open (null)
on any subsequent invocation. The code should probably simply return immediately
if !ptr->filename as a starting fix, then one could at least read the real error
message, instead of printing "can't open (null)" over and over.

That said, something is wildly wrong; strace of my test suite reveals:

 182 execve()
 182 exit_group()
 1477 open() of EACH .da file for a total of 70888 opens (and each 
      open is followed by a pile of seeks)

Trying to single-step through __bb_exit_func isn't going well, gcc debuginfo
doesn't help. gdb seems to get confused and doesn't find the debuginfo (and the
"step"/"next" commands simply hang).

Comment 4 Havoc Pennington 2003-10-16 02:58:53 EDT
hmm, but I get no non-(null) filename error message before the (null) starts.
Comment 5 Havoc Pennington 2003-10-21 01:46:35 EDT
Created attachment 95340 [details]
test case, compile with -fprofile-arcs -ftest-coverage
Comment 6 Havoc Pennington 2003-10-21 01:52:35 EDT
This looks pretty simple now that I debugged it. In libgcc2.c, if 
"error || !merging" we set ptr->filename to NULL, and then for all 
subsequent calls to __bb_exit_func() pass the null pointer to fopen().

What I don't understand is why in the !merging case ptr->filename is 
set to NULL.

So two actions probably needed:
 - understand why if !merging we disable future .da file writes
 - cleanly if (!ptr->filename) continue; instead of passing the 
   null pointer to fopen()

Also, I may be missing something, but the code seems to try to acquire a lock
with fcntl() but blissfully ignore failure to obtain said lock. I have a patch
that will do something like "while (don't have the lock) sleep ()"
Comment 7 Havoc Pennington 2003-10-21 14:41:13 EDT
Moved upstream as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12711

Note You need to log in before you can comment on or make changes to this bug.