My system is Ubuntu 64 bits Lucid Lynx. with this following small program, I obtain a crazy segmentation fault in strchr() with gcc4.4.3-4ubuntu5 AND NOT with gcc4.4.1-4ubuntu9 (with same glibc in both case) : // gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 -> execution gives a "segmentation fault" // gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1 -> execution is fully OK #include <stdio.h> #include <string.h> char t[]="It: is a gcc4.4.3 bug"; main() { char *p; puts(t); p = strchr(t, ':'); printf("p='%s'\n", p); return 0; } Many best regards. Eric.
Works for me (thus I suggest to file a bug with Ubuntu). Which optimization options? Please attach preprocessed source.
Created attachment 20234 [details] Preprocessed source not OK with "gcc -E main.c"
Created attachment 20235 [details] Preprocessed source OK with "gcc -E main.c"
Created attachment 20236 [details] a.out OK obtained by command "gcc main.c"
Created attachment 20237 [details] a.out not OK obtained by command "gcc main.c"
Here are new files (preprocessed sources OK and not OK) and binaries obtained only with command "gcc main.c"
Created attachment 20238 [details] a.out OK obtained by command "gcc -g main.c" (with debug infos on 64bit ubuntu)
Created attachment 20239 [details] a.out not OK obtained by command "gcc -g main.c" (with debug infos on 64bit ubuntu)
Created attachment 20240 [details] File obtained with command "strace -s 1024 ./a_ok_withdebug.out > strace_s1024_a_ok.txt 2>&1"
Created attachment 20241 [details] File obtained with command "strace -s 1024 ./a_nok_withdebug.out > strace_s1024_a_nok.txt 2>&1"
Created attachment 20242 [details] File obtained with command "strace -s 1024 ./a_nok_withdebug.out > strace_s1024_a_nok.txt 2>&1" (executed on the SAME SYSTEM than file attachment #20240 [details] that was OK)
i can confirm that gpf on my system (gcc-4.4.4, glibc-2.11.1). i see diffs in relocations. $ readelf -sW a_ok*|grep strchr 5: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strchr@GLIBC_2.2.5 (2) 70: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strchr@@GLIBC_2.2.5 $ readelf -sW a_nok*|grep strchr 5: 0000000000601050 41 IFUNC GLOBAL DEFAULT 26 strchr@GLIBC_2.2.5 (2) 69: 0000000000601050 41 IFUNC GLOBAL DEFAULT 26 strchr@@GLIBC_2.2.5
Dear Pawel, Please could you tell me exactly if you had gpf on your system by recompiling and then executing my main.c ? Many thanks for your contribution. Eric. (In reply to comment #12) > i can confirm that gpf on my system (gcc-4.4.4, glibc-2.11.1). > i see diffs in relocations. > > $ readelf -sW a_ok*|grep strchr > 5: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strchr@GLIBC_2.2.5 (2) > 70: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strchr@@GLIBC_2.2.5 > > $ readelf -sW a_nok*|grep strchr > 5: 0000000000601050 41 IFUNC GLOBAL DEFAULT 26 strchr@GLIBC_2.2.5 (2) > 69: 0000000000601050 41 IFUNC GLOBAL DEFAULT 26 strchr@@GLIBC_2.2.5 >
(In reply to comment #13) > Dear Pawel, > Please could you tell me exactly if you had gpf on your system by recompiling > and then executing my main.c ? i've only ran attached binaries (a_{n}ok_withdebug.out) under gdb.
What's happened if you recompile and run main.c with your gcc4.4.4 ? (In reply to comment #14) > (In reply to comment #13) > > Dear Pawel, > > Please could you tell me exactly if you had gpf on your system by recompiling > > and then executing my main.c ? > > i've only ran attached binaries (a_{n}ok_withdebug.out) under gdb. >
Created attachment 20246 [details] main.c with segmentation fault if compiled with gcc-4.4.3
(In reply to comment #15) > What's happened if you recompile and run main.c with your gcc4.4.4 ? works fine because my toolchain doesn't emit STT_GNU_IFUNC mark for strchr() symbol. you should ask Ubuntu support about this issue.
Thanks Pawel. (In reply to comment #17) > (In reply to comment #15) > > What's happened if you recompile and run main.c with your gcc4.4.4 ? > > works fine because my toolchain doesn't emit STT_GNU_IFUNC > mark for strchr() symbol. you should ask Ubuntu support about > this issue. >
Maybe HJL has an idea, too.
(In reply to comment #12) > i can confirm that gpf on my system (gcc-4.4.4, glibc-2.11.1). > i see diffs in relocations. > > $ readelf -sW a_ok*|grep strchr > 5: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strchr@GLIBC_2.2.5 (2) > 70: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strchr@@GLIBC_2.2.5 > > $ readelf -sW a_nok*|grep strchr > 5: 0000000000601050 41 IFUNC GLOBAL DEFAULT 26 strchr@GLIBC_2.2.5 (2) > 69: 0000000000601050 41 IFUNC GLOBAL DEFAULT 26 strchr@@GLIBC_2.2.5 > This is a linker bug. Please report it to Ubuntu. Undefined functions should never be marked as IFUNC.
OK, I'm going to transfer this problem to Ubuntu. The linker is GNU ld in package binutils, isn't it ? (In reply to comment #20) > (In reply to comment #12) > > i can confirm that gpf on my system (gcc-4.4.4, glibc-2.11.1). > > i see diffs in relocations. > > > > $ readelf -sW a_ok*|grep strchr > > 5: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strchr@GLIBC_2.2.5 (2) > > 70: 0000000000000000 0 FUNC GLOBAL DEFAULT UND strchr@@GLIBC_2.2.5 > > > > $ readelf -sW a_nok*|grep strchr > > 5: 0000000000601050 41 IFUNC GLOBAL DEFAULT 26 strchr@GLIBC_2.2.5 (2) > > 69: 0000000000601050 41 IFUNC GLOBAL DEFAULT 26 strchr@@GLIBC_2.2.5 > > > > This is a linker bug. Please report it to Ubuntu. Undefined > functions should never be marked as IFUNC. >
(In reply to comment #21) > OK, I'm going to transfer this problem to Ubuntu. > The linker is GNU ld in package binutils, isn't it ? > There may be 2 linkers. In any case, just report it to Ubuntu.
only seen with gold (2.20.1). gold from the trunk does work.
I checked on my Ubuntu 64bit Lucid Lynx system that generates bad binary : 1) binutils (2.20.1-3ubuntu1) is installed 2) binutils-gold (2.20-0ubuntu2) is NOT installed (In reply to comment #23) > only seen with gold (2.20.1). gold from the trunk does work. >
I've reported this problem to Ubuntu at this following URL : https://bugs.launchpad.net/ubuntu/+bug/551245