While tackling this bug ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31998 ) I
found a problem with the boehm-gc. This is a seperate bug report only about
boehm-gc (and not about the interrelated issues of the above report).
/gcc/xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /root/downloads/gcc-4_2-branch/configure --verbose
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp
--prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib
--with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug
--enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit
--enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp
--enable-libmudflap --enable-libgomp --disable-werror --enable-nls
--with-included-gettext --enable-decimal-float --with-long-double-128
--enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo
--enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers
--with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile
--with-stabs --enable-hash-synchronization --enable-gc-debug
--enable-interpreter --with-system-zlib --enable-libada --with-tls
--with-cpu=athlon-xp --with-arch=athlon-xp
--enable-stage1-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree
Thread model: posix
gcc version 4.2.1 20070515 (prerelease)
Three things.
1): When running "make -i check" the boehm tests don't make "gctest" correctly.
I had to build gctest by hand and it _seems_ to work. I am debugging a error
that is the subject of a different bug report so I had to branch over to check
if there was a problem with boehm-gc.
Here is the output of "make -i check":
# /opt/gcc-4_2-build/./gcc/xgcc -B/opt/gcc-4_2-build/./gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem
/usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include
-fexceptions -Iinclude -I././targ-include -I.//libc/include
-I/root/downloads/gcc-4_2-branch/boehm-gc/include -O2 -g -O2 -o .libs/gctest
-shared-libgcc /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c
/root/downloads/gcc-4_2-branch/boehm-gc/pthread_support.c ./.libs/libgcjgc.so
-lpthread -ldl
/tmp/ccTiGNJU.o: In function `mktree':
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:798: undefined reference
to `GC_local_malloc'
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:807: undefined reference
to `GC_local_malloc_atomic'
/tmp/ccTiGNJU.o: In function `local_cons':
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:264: undefined reference
to `GC_local_malloc'
/root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:267: undefined reference
to `GC_local_gcj_malloc'
collect2: ld returned 1 exit status
#
Add -DGC_DEBUG and the compile error goes away (since that avoids the defines,
but doesn't fix the _actual_ problem). I'll build it static:
# /opt/gcc-4_2-build/./gcc/xgcc -DGC_DEBUG -B/opt/gcc-4_2-build/./gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem
/usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include
-fexceptions -Iinclude -I././targ-include -I.//libc/include
-I/root/downloads/gcc-4_2-branch/boehm-gc/include -O2 -g -O2 -o .libs/gctest
-static /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c
/root/downloads/gcc-4_2-branch/boehm-gc/pthread_support.c ./.libs/libgcjgc.a
-lpthread -ldl
# .libs/gctest
Completed 3 tests
Allocated 4863995 collectable objects
Allocated 303 uncollectable objects
Allocated 3750000 atomic objects
Allocated 34440 stubborn objects
Finalized 3302/3302 objects - finalization is probably ok
Total number of bytes allocated is 621142336
Final heap size is 20967424 bytes
Collector appears to work
Completed 195 collections
#
Each time you run gctest the test passes but the numbers above are a little
different - depending on available memory at a particular moment.
Which means it is non-deterministic (can interfere with debugging).
2): I don't know that boehm is integrated with GCC in accordance with the
recommendations provided in the boehm DOCs.
The file: file:///root/downloads/gcc-4_2-branch/boehm-gc/doc/README.linux says:
To use threads, you need to abide by the following requirements:
...
2) You must compile the collector with -DGC_LINUX_THREADS and -D_REENTRANT
specified in the Makefile.
3a) Every file that makes thread calls should define GC_LINUX_THREADS and
_REENTRANT and then include gc.h. Gc.h redefines some of the
pthread primitives as macros which also provide the collector with
information it requires.
3b) A new alternative to (3a) is to build the collector and compile GC clients
with -DGC_USE_LD_WRAP, and to link the final program with
(for ld) --wrap read --wrap dlopen --wrap pthread_create \
--wrap pthread_join --wrap pthread_detach \
--wrap pthread_sigmask --wrap sleep
(for gcc) -Wl,--wrap -Wl,read -Wl,--wrap -Wl,dlopen -Wl,--wrap \
-Wl,pthread_create -Wl,--wrap -Wl,pthread_join -Wl,--wrap \
-Wl,pthread_detach -Wl,--wrap -Wl,pthread_sigmask \
-Wl,--wrap -Wl,sleep
In any case, _REENTRANT should be defined during compilation.
4) Dlopen() disables collection during its execution. (It can't run
concurrently with the collector, since the collector looks at its
data structures. It can't acquire the allocator lock, since arbitrary
user startup code may run as part of dlopen().) Under unusual
conditions, this may cause unexpected heap growth.
5) The combination of GC_LINUX_THREADS, REDIRECT_MALLOC, and incremental
collection fails in seemingly random places. This hasn't been tracked
down yet, but is perhaps not completely astonishing. The thread package
uses malloc, and thus can presumably get SIGSEGVs while inside the
package. There is no real guarantee that signals are handled properly
at that point.
Checking for the word "_REENTRANT" in the logging of my make I find:
# grep _REENTRANT /opt/gcc-4_2-build/made_3_profiled_log.txt
/opt/gcc-4_2-build/made_3_profiled_log.txt:checking whether gethostbyname_r
declaration requires -D_REENTRANT... fail
That word comes from the configuration of i686-pc-linux-gnu/libjava and is not
relevant:
checking for gethostbyname_r... yes
checking whether gethostbyname_r declaration requires -D_REENTRANT... fail
checking for struct hostent_data... no
Checking for the word "pthread_sigmask" in the logging of my make I find,
nothing:
# grep pthread_sigmask /opt/gcc-4_2-build/made_3_profiled_log.txt
#
Even if we were following rules 2, 3a or 3b, and 4 we may get hit by rule 5
"collection fails in seemingly random places". I observed such difficulties
trying to use gdb. It did not _seem_ that boehm-gc failed but GC did make
it tough to debug because what I was looking for was memory related and thus
I had a moving target affecting how many times what I was tracing could be
executed (EG: sometimes "c 30" would skip the correct number of breakpoint
and then "step" would be at the bug - and sometimes that did not work).
Every time I run gctest the it says it passes but the values do not match.
It runs a different number of collections (based on available memory at the
moment it is ran). It says "finalization is probably ok" and "Collector
appears to work", which is not saying it is certain.
3): Numer 2 makes fixing this one harder. While working on the bug mentioned at
the top of this report I got this error:
Base64.java:200: warning: Unreachable statement.
for (i = off; i < off + len; i++)
^
1 warning
Base64.java: At top level:
Base64.java:50: internal compiler error: in uses_jv_markobj_p, at
java/boehm.c:245
Please submit a full bug report, ...
I started gdb like this:
# gdb --args /opt/gcc-4_2-build/gcc/xgcc -v
-B/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/ -B/opt/gcc-4_2-build/gcc/
-ffloat-store -fomit-frame-pointer -fclasspath=
-fbootclasspath=/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -MT
gnu/java/security/util.lo -MD -MP -MF Base64.deps Base64.java -fPIC -o Base64.o
Here is how the error is debugged:
(gdb) start
Breakpoint 1 at 0x8053f04: file /root/downloads/gcc-4_2-branch/gcc/gcc.c, line
6090.
Starting program: /opt/gcc-4_2-build/gcc/xgcc -v
-B/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/ -B/opt/gcc-4_2-build/gcc/
-ffloat-store -fomit-frame-pointer -fclasspath=
-fbootclasspath=/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -MT
gnu/java/security/util.lo -MD -MP -MF Base64.deps Base64.java -fPIC -o Base64.o
main (argc=-1078606192, argv=0xb7e17e6d) at
/root/downloads/gcc-4_2-branch/gcc/gcc.c:6090
6090 p = argv[0] + strlen (argv[0]);
(gdb) where
#0 main (argc=-1078606192, argv=0xb7e17e6d) at
/root/downloads/gcc-4_2-branch/gcc/gcc.c:6090
(gdb) l 5800
5795 goto invalid;
5796 p++;
5797 }
5798
5799 end_body = p;
5800 while (end_body[-1] == ' ' || end_body[-1] == '\t')
5801 end_body--;
5802
5803 if (have_subst && !starred)
5804 goto invalid;
(gdb) l 4635
4630
4631 set_collect_gcc_options ();
4632
4633 if (argbuf_index > 0)
4634 {
4635 value = execute ();
4636 if (value)
4637 return value;
4638 }
4639 /* Reinitialize for a new command, and for a new argument. */
(gdb) (gdb) info breakp
Num Type Disp Enb Address What
38 breakpoint keep y 0x080533dd in handle_braces at
/root/downloads/gcc-4_2-branch/gcc/gcc.c:5800
breakpoint already hit 37 times
(gdb) b 4635
(gdb) c
Continuing.
Breakpoint 39, do_spec_1 (spec=0x807e018 "-o %|.s |\n as %(asm_options) %|.s
%A", inswitch=0, soft_matched_part=0x0)
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:4635
4635 value = execute ();
(gdb) where
#0 do_spec_1 (spec=0x807e018 "-o %|.s |\n as %(asm_options) %|.s %A",
inswitch=0, soft_matched_part=0x0)
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:4635
#1 0x080534b7 in handle_braces (p=0x8082585 "-o %|.s |\n as %(asm_options)
%|.s %A }")
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5814
#2 0x08050c19 in do_spec_1 (spec=0x8082580 "%{!S:-o %|.s |\n as %(asm_options)
%|.s %A }", inswitch=0,
soft_matched_part=0x0) at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5204
#3 0x08050d9b in do_spec_1 (spec=0x8086048 "%(invoke_as)", inswitch=0,
soft_matched_part=0x0)
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5303
#4 0x080534b7 in handle_braces (p=0x8085fa9 "%(invoke_as)}") at
/root/downloads/gcc-4_2-branch/gcc/gcc.c:5814
#5 0x08050c19 in do_spec_1 (
spec=0x8085f20 "jc1 %i %(jc1) %(cc1_options) %{+e*} %{I*}", ' ' <repeats 13
times>, "%{MD:-MD_} %{MMD:-MMD_} %{M} %{MM} %{MA} %{MT*} %{MF*}", ' ' <repeats
13 times>, "%{!fsyntax-only:%(invoke_as)}", inswitch=0, soft_matched_part=0x0)
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5204
#6 0x080534b7 in handle_braces (
p=0x8069046 "jc1 %i %(jc1) %(cc1_options) %{+e*} %{I*}", ' ' <repeats 13
times>, "%{MD:-MD_} %{MMD:-MMD_} %{M} %{MM} %{MA} %{MT*} %{MF*}", ' ' <repeats
13 times>, "%{!fsyntax-only:%(invoke_as)}}")
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5814
#7 0x08050c19 in do_spec_1 (
spec=0x8068ee0 "%{fjni:%{femit-class-files:%e-fjni and -femit-class-files
are incompatible}} %{fjni:%{femit-class-file:%e-fjni and -femit-class-file
are incompatible}} %{femit-class-file:%{!fsyntax-only:%e-femi"...,
inswitch=0,
soft_matched_part=0x0) at /root/downloads/gcc-4_2-branch/gcc/gcc.c:5204
#8 0x08053a3d in do_spec_2 (
spec=0x8068ee0 "%{fjni:%{femit-class-files:%e-fjni and -femit-class-files
are incompatible}} %{fjni:%{femit-class-file:%e-fjni and -femit-class-file
are incompatible}} %{femit-class-file:%{!fsyntax-only:%e-femi"...)
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:4420
#9 0x08053e6c in do_spec (
spec=0x8068ee0 "%{fjni:%{femit-class-files:%e-fjni and -femit-class-files
are incompatible}} %{fjni:%{femit-class-file:%e-fjni and -femit-class-file
are incompatible}} %{femit-class-file:%{!fsyntax-only:%e-femi"...)
at /root/downloads/gcc-4_2-branch/gcc/gcc.c:4388
#10 0x08054ae1 in main (argc=Cannot access memory at address 0x0
) at /root/downloads/gcc-4_2-branch/gcc/gcc.c:6628
(gdb) step
execute () at /root/downloads/gcc-4_2-branch/gcc/gcc.c:2797
2797 gcc_assert (!processing_spec_function);
1): I think that is clear. Load the Base64.o Java file and start the debugger.
2): List two parts of the code to show that your line numbers are the same as
mine. I did not alter the source but you might want to try on a different
version of gcc.
3): Place the two breakpoints on those same lines.
4): Run the program and hit the breakpoint.
5): On _that_ particular run of _GDB_ the memory was in a state where I
_usually_ (but sometimes not) had to use "c 36" to jump the breakpoint.
Because boehm-gc is changing things (along with the OS) sometimes I need
to use a different number after the "c". Once I found out the number I
could use "r" to restart gdb and then use "c #" to jump the breakpoints.
6): AFTER figuring out the number for "c" for a _particular_ run of gdb I could
easily get to the point where I simply add one more breakpoint and type
"c" (without a following number) to land exactly on the instruction that
caused the ICE when I typed "n" at the gdb prompt.
Those problems with boehm-gc (the boehm-gc DOCs admit to random occurances of
trouble) make debugging tough _AND_ might have been the cause of some of the
languages and libraries "make -i check" tests failing.
We did not seem to follow all the DOCs when integrating boehm with gcc - I will
check more carefully. _EVEN_ _IF_ we did, the DOCs says that random failures
occur that have not been tracked down.
The gctest is not getting built when ./configure uses the above options.
--
Summary: "Make -i check" finds one, and fails to find another,
boehm-gc problem
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: boehm-gc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31999
