Bug 107096 - arc profiling tries to open null output file
Summary: arc profiling tries to open null output file
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-14 23:09 UTC by Havoc Pennington
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-21 18:41:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

Description Havoc Pennington 2003-10-14 23:09:24 UTC
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-15 00:27:34 UTC
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-15 03:15:44 UTC
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 23:25:52 UTC
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 06:58:53 UTC
hmm, but I get no non-(null) filename error message before the (null) starts.

Comment 5 Havoc Pennington 2003-10-21 05:46:35 UTC
Created attachment 95340 [details]
test case, compile with -fprofile-arcs -ftest-coverage

Comment 6 Havoc Pennington 2003-10-21 05:52:35 UTC
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 18:41:13 UTC
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.