Hide Forgot
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 fopen). 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:
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?
rpm -q glibc returns glibc-2.3.2-95.3 I tried all 3 of the Electric fence env variables and got mixed results. -------------------------------------------------------------------- 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 ggmGraphicReport.c:253 ---------------------------------------------------------------- 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 ) { exit; } else 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... Brian
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.
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.