Bug 120714

Summary: Electric Fence calls out fopen for buffer overrun.
Product: Red Hat Enterprise Linux 3 Reporter: Brian Jones <b3.jones>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED WORKSFORME QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 3.0CC: drepper.fsp
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-25 11:37:11 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Brian Jones 2004-04-13 09:21:56 EDT
Description of problem:

I am compiling and linking an executable with electric fence to check 
our software for memory issues.  Problem is that electric fence 
crashes on the first call to fopen and points to /lib/tls/libc.so.6 
and is complaining about an _IO_old_file_init()?  

I am using ddd to backtrace the stack to get this information.

I thought this looked similar to bug 90077, but I cannot confirm that 
it is the same problem nor that it is fixed.

Everything I am passing to fopen looks fine, and I am confused as to 
why electric fence would flag a call to fopen as a buffer overrun.

I am using the "stable" version of glibc.  GNU CC version 3.2.3 
20030502 as returned by the stings command on the object file.

I just started using electric fence so I am not at all an expert on 
it, but it is pretty clear from the backtrace info that it is blowing 
up in libc.so.6.

Please give guidence......

Version-Release number of selected component (if applicable):
3.2.3 "Stable" 20030502

How reproducible:
Every time I call the first fopen in our code after I have compiled 
and linked with -lefence.

Steps to Reproduce:
1.  Compile executable with -lefence option.
2.  Execute compile code with ddd (make sure there is a call to 
3.  Backtrace after SigSev on call to fopen.

Actual results:
Electric Fence produces SIGSEV at call to fopen().

Expected results:
File would open normally and execution continue until electric fence 
flags something else.

Additional info:
Comment 1 Jakub Jelinek 2004-04-14 07:14:34 EDT
glibc version certainly is not 3.2.3, that is GCC version.
You can get glibc version by running rpm -q glibc.
I have compiled/linked:
#include <stdio.h>

int main (void)
  FILE *f = fopen ("/etc/passwd", "r");
  fclose (f);
  return 0;
and it shows no problems under LD_PRELOAD=libefence.so.0
nor EF_PROTECT_BELOW=1 LD_PRELOAD=libefence.so.0.

This is with glibc-2.3.2-95.20.
Can you attach a testcase which reproduces the behaviour you're seeing?
Comment 2 Brian Jones 2004-04-14 15:12:23 EDT
rpm -q glibc returns glibc-2.3.2-95.3

I tried all 3 of the Electric fence env variables and got mixed 

First with none of the 3 set, and ldd showing my executable dependant 
upon libefence.so.0, I get from the ddd backtrace:

Program recieved signal SIGSEV, Segmentation fault.
#0   0xb6f67c94 in _IO_old_file_int () from /lib/tls/libc.so.6
#1   0xb6f61e62 in fopen@GLIBC_2.0 () from /lib/tls/libc.so.6
#2   0xb74d79f1 in gglLoadGraphic (file=0xb74d2120
#3   0xb74d1a3e in main (argc=2, argv=0xbfffce84) at 

Whith just EF_PROTECT_BELOW=1 set, my executable runs but other 
actions cause ddd to report (as the executable crashes):

ElectricFence Exiting: mmap() failed: Cannot allocate memory
Program exited with code 0377.

No Stack available for a backtrace.

With both EF_PROTECT_BELOW=1 and EF_PROTECT_FREE=1 set, executable 
does not run and ddd reports:

ElectricFence Exiting: mprotect() failed: Cannot allocate memory
Program exited with code 0377.

No Stack available for a backtrace.

Finally I tried not setting the previous two and just setting 
EF_ALLOW_MALLOC_0=1 and got the same results as the case with none of 
the 3 set (ie fopen kills electric fence).

With all 3 set I get the result as with just EF_PROTECT_BELOW=1 and 
EF_PROTECT_FREE=1 set.....

ElectricFence Exiting: mprotect() failed: Cannot allocate memory
Program exited with code 0377.

No Stack available for a backtrace.

The code I am running looks something like this...

void gglLoadGraphic( char *file, GR_DMEM *gr_dmem )
   FILE *fs;

   gr_dmem->graphic_file = (char*)calloc(strlen(file), sizeof(char*));

   if ( gr_dmem->graphic_file == NULL )

     strncpy( gr_dmem->graphic_file, file );

   fs = fopen( (const char*)gr_dmem->graphic_file, "r" )

   "do other stuff after fopen works"

I am under the assumption that there are other problems in our 
code... but I can't get there (to where the real problems are) 
because fopen dies....

Thanks for the follow-up, I hope this helps.

I am getting close to pulling my hair out over this so any help you 
can give me will be appreciated very much...


Comment 3 Ulrich Drepper 2004-09-30 06:51:05 EDT
We cannot reproduce any problem.  Maybe you can try a bit more
reliable memory debugger?  Maybe valgrind (valgrind.kde.org) will
work.  If you can produce a self-contained example of the failing code
we can look at it.  But the code is in use in thousands of
applications and we do not see any problems.
Comment 4 Jakub Jelinek 2004-10-25 11:37:11 EDT
Even in the code you posted there are several bugs before the fopen
call (unless they are typos created during typing things here by hand).
Anyway, without a self-contained testcase there is nothing we can do, so once you
have something, please reopen.