Created attachment 425240 [details] source tar file Description of problem: When a kernel module (generated by systemtap) is compiled, gcc reports an internal compiler error and gets a segmentation fault. Version-Release number of selected component (if applicable): gcc-4.1.2-48.el5 kernel-2.6.18-194.el5 kernel-devel-2.6.18-194.el5 How reproducible: Happens every time. Steps to Reproduce: # tar jxf reproducer.tar.bz2 # make -C /lib/modules/2.6.18-194.el5/build M=`pwd`/reproducer ARCH="powerpc" modules V=1 Actual results: # make -C /lib/modules/2.6.18-194.el5/build M=`pwd`/reproducer ARCH="powerpc" modules V=1 make: Entering directory `/usr/src/kernels/2.6.18-194.el5-ppc64' test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \ echo; \ echo " ERROR: Kernel configuration is invalid."; \ echo " include/linux/autoconf.h or include/config/auto.conf are missing."; \ echo " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo; \ /bin/false) mkdir -p /root/ppc/reproducer/.tmp_versions rm -f /root/ppc/reproducer/.tmp_versions/* make -f scripts/Makefile.build obj=/root/ppc/reproducer gcc -m64 -Wp,-MD,/root/ppc/reproducer/.stap_16929.o.d -nostdinc -isystem /usr/lib/gcc/ppc64-redhat-linux/4.1.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Wstrict-prototypes -Wundef -Werror-implicit-function-declaration -fno-delete-null-pointer-checks -fwrapv -Os -msoft-float -pipe -mminimal-toc -mtraceback=none -mcall-aixdesc -mtune=power4 -mno-altivec -funit-at-a-time -mstring -Wa,-maltivec -fomit-frame-pointer -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -Iinclude2/asm/mach-default -include /tmp/stapyoaCsq/stapconf_5c46f822e8a43ee3ca3292dcc51cfc81_427.h -freorder-blocks -Wno-unused -Werror -I"/usr/local/share/systemtap/runtime" -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(stap_16929)" -D"KBUILD_MODNAME=KBUILD_STR(stap_16929)" -c -o /root/ppc/reproducer/.tmp_stap_16929.o /root/ppc/reproducer/stap_16929.c /root/ppc/reproducer/stap_16929.c: In function ‘enter_profile_probes’: /root/ppc/reproducer/stap_16929.c:346: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugzilla.redhat.com/bugzilla> for instructions. Preprocessed source stored into /tmp/cchfsYNu.out file, please attach this to your bugreport. make[1]: *** [/root/ppc/reproducer/stap_16929.o] Error 1 make: *** [_module_/root/ppc/reproducer] Error 2 make: Leaving directory `/usr/src/kernels/2.6.18-194.el5-ppc64' Expected results: A compiled module, not a segfault. Additional info: The reproducer tar file includes a preprocessed source file, called 'ccw3R6PE.out'.
This crashes in set_uids_in_ptset, in else if (var_can_have_subvars (vi->decl) && get_subvars_for_var (vi->decl)) { /* If VI->DECL is an aggregate for which we created SFTs, add the SFT corresponding to VI->OFFSET. */ tree sft = get_subvar_at (vi->decl, vi->offset); bitmap_set_bit (into, DECL_UID (sft)); } get_subvar_at (vi->decl, vi->offset) for vi->decl global, vi->offset 96 is NULL. static struct { int64_t s_f; rwlock_t s_f_lock; atomic_t s_f_lock_skip_count; } global = { .s_f_lock_skip_count = { (0) }, }; create_overlap_variables_for only creates sft for s_f, because up_lookup says up->max_used == 64. The http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00057.html patch for 4.2 removed anyoffset handling (not desirable for 4.1 of course) and also without any comment added if (sft) right before the bitmap_set_bit, I wonder if that one liner couldn't be safe in this case.
Created attachment 425575 [details] gcc41-rh605803.patch Another, perhaps safer, version. Instead of crashing just assume it can point to anything.
Created attachment 425577 [details] gcc41-rh605803.patch Another, perhaps safer, version. Instead of crashing just assume it can point to anything.
In gcc-4.1.2-49.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0025.html