When I am trying to compile and run this small program #include <stdio.h> #include <gtk/gtk.h> void close() { printf("I am here.\n"); exit(1); } void make_win() { GtkWidget *win; win = gtk_window_new( GTK_WINDOW_TOPLEVEL ); return 0; } int main(int argc, char** argv) { printf("first\n"); gtk_init(&argc,&argv); make_win(); return 0; } with command gcc test.c `pkg-config --cflags --libs gtk+-2.0` then function close is called on load of program instance. But there are no any call to this function. Fedore Core 2 and Suse 8 are not affected to this bug. Reproducible: Always Steps to Reproduce: 1. Compile program. 2. Run it. 3. Actual Results: Function close is called on load of instance of the program. Expected Results: No any calls to close function.
Test system was Gentoo 2004.3 with gcc 3.3.5.
close() is a system call. Rename the function, otherwise you get an undefined behaviour. You should #include <unistd.h> then you would get the right error message at compile time. close() is indeed called in the bootstrap code, the little piece, which comes before main(). I compiled it with -g, then> gdb ./a.out ... (gdb) b close Breakpoint 1 at 0x40094c: file tt.c, line 7. (gdb) r Starting program: /home/roland/e/a.out Breakpoint 1, close () at tt.c:7 7 printf("I am here.\n"); (gdb) bt #0 close () at tt.c:7 #1 0x0000002a967d9025 in __guard_setup () from /lib/libc.so.6 #2 0x0000002a967d8e25 in __libc_start_main () from /lib/libc.so.6 #3 0x00000000004008ba in _start () Having then an exit(), the app exits....
I know this that bootstrap calls the close function. But I think normal behaviour should be that the close function in the example program is not called. This is true at least for Fedore Core 2 and Suse.
> objdump -T /lib/libc.so.6 |grep close ... 00000000000aa6a0 w DF .text 0000000000000070 GLIBC_2.2.5 close .... You see "w"eak, so in your case, your local implementation will be choosen.
For Fedore Core 2 I have with objdump -T /lib/libc.so.6 |grep close 000af1c0 w DF .text 00000071 GLIBC_2.0 __close 000af1c0 w DF .text 00000071 GLIBC_2.0 close but close function from test code is not called.
really, overriding system functions is a stupid idea
This is the stack-protector initialisation function (__guard_setup), which incorrectly calls the public symbols for open(), read(), close() etc, when it should use internal glibc interfaces when it is integrated into glibc. See bug #65892 - added as a dependency for this bug. Pappy is working on fixing this properly, but in the meantime the replacement ssp.c on bug #65782 (attachment id #49704) can resolve the issue.
That last statement should read 65892 not 65782 of course.
I have recompiled glibc with new ssp.c from Kevin F. Quinn. Just for program without any addition libraries all is working correctly. But for program that uses gtk library, for example, like in the beginning of this bug description the close function is still called even if it is not called anywhere in program. Now it looks like this function called on exit of program.
close() is called from the gtk+2.0 library on shutdown, which is perfectly normal (how else will it close open file descriptors...). Overloading it will cause the library to call your close instead of that in glibc. The underlying reason is that the loader permits symbol overloading in shared libraries. As others have said above, writing functions with the same name as those in the standard library is a bad idea. FWIW the ssp code is different, in that for several reasons it shouldn't be overloadable, not least to prevent library pre-loading being used to de-fang the ssp.
*** This bug has been marked as a duplicate of 65892 ***
