Bug 120714 - Electric Fence calls out fopen for buffer overrun.
Summary: Electric Fence calls out fopen for buffer overrun.
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-13 13:21 UTC by Brian Jones
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2004-10-25 15:37:11 UTC

Attachments (Terms of Use)

Description Brian Jones 2004-04-13 13:21:56 UTC
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 11:14:34 UTC
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 19:12:23 UTC
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 10:51:05 UTC
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 15:37:11 UTC
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.

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