Bug 291341 - gcc fails to find right header file, possibly resulting in silent miscompilation of code
gcc fails to find right header file, possibly resulting in silent miscompilat...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gcc (Show other bugs)
3.9
All Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-14 13:39 EDT by Anthony Green
Modified: 2010-10-22 14:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-08 12:40:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A patch to fix the problem. (831 bytes, patch)
2007-09-14 13:39 EDT, Anthony Green
no flags Details | Diff

  None (edit)
Description Anthony Green 2007-09-14 13:39:07 EDT
Description of problem:

On very rare occasions gcc will fail to open and read the right header file.  In
the cases where we've seen it, gcc reports that the header couldn't be found -
but gcc could just as easily read the wrong header if a file with the same name
is found later in the search path, possibly resulting in silent miscompilation
of code.

The bug was introduced with this patch:
http://gcc.gnu.org/ml/gcc-bugs/2001-05/msg00141.html

Here's the whole find_or_create_entry...

find_or_create_entry (pfile, fname)
     cpp_reader *pfile;
     const char *fname;
{
  splay_tree_node node;
  struct include_file *file;
  char *name = xstrdup (fname);

  _cpp_simplify_pathname (name);
  node = splay_tree_lookup (pfile->all_include_files, (splay_tree_key) name);
  if (node)
    free (name);
  else
    {
      file = xcnew (struct include_file);
      file->name = name;
      file->err_no = errno;
      node = splay_tree_insert (pfile->all_include_files,
                                (splay_tree_key) file->name,
                                (splay_tree_value) file);
    }

  return node;
}

Note that this code assumes that errno doesn't change between
"_cpp_simplify_pathname (name)" and "file->err_no = errno;".  
Unfortunately this is not the case. On very rare occasions it is possible that
the calloc() call wrapped in "file = xcnew (struct include_file);" will set
errno even on successful calls.  The strace output of the compiler suggests that
we're expanding the heap (brk/mmap2 system calls) during this calloc() call,
which is one of the conditions under which calloc() may set errno.
gcc later will avoid trying to open the header file based on the value of
file->err_no.

I'll submit a patch that simply preserves the value of errno around the calloc()
call.

Version-Release number of selected component (if applicable):
gcc-3.2.3-59

How reproducible:
Very rarely, as it depends on the exact memory allocation pattern of the compile
run.

Steps to Reproduce:
1.Only the customer is able to reproduce by compiling their large project.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Anthony Green 2007-09-14 13:39:07 EDT
Created attachment 196041 [details]
A patch to fix the problem.
Comment 9 RHEL Product and Program Management 2007-10-19 14:35:20 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.
Comment 14 Jakub Jelinek 2009-09-08 12:40:17 EDT
Marking as fixed in RHEL4+.

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