Discussion:
[Gc] gc make fail on Solaris 10 x86_64 with gcc-3.* & -m64 option
(too old to reply)
Kiyoshi KANAZAWA
2012-03-25 11:42:58 UTC
Permalink
Hello,

I tried to build 64bits gc-7.1 on Solaris 10 x86_64. but failed with message:
libatomic_ops/src/atomic_ops.h:197,
from ./include/private/gc_locks.h:30,
from ./include/private/gc_priv.h:85,
from alloc.c:19:
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:9:23: xmmintrin.h: No such file or directory
In file included from libatomic_ops/src/atomic_ops/sysdeps/gcc/x86_64.h:37,
from libatomic_ops/src/atomic_ops.h:197,
from ./include/private/gc_locks.h:30,
from ./include/private/gc_priv.h:85,
from alloc.c:19:
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:10: error: syntax error before "double_ptr_storage"
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:10: warning: data definition has no type or storage class
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:30: error: syntax error before "double_ptr_storage"
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:30: warning: no semicolon at end of struct or union
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:32: error: syntax error before '}' token
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:32: warning: data definition has no type or storage class
make[1]: *** [alloc.lo] Error 1

This occurs with gcc-3.4.3 & -m64 option.
Passes with gcc-4.4.7 & -m64.
I tried gc-7.2alpha6 but had the same result.
I'm afraid algorithm to find "GCC_PATH/lib/gcc/i386-pc-solaris-version/GCC_VERSION/install-tools/include" depends on gcc version.

gcc-3.4.3 is included in Solaris10 distribution.
Many GNU softwares, including gc, are required to build newer gcc.
(I once built them with -m32, and now trying with -m64)

Best regards,

--- Kiyoshi <***@yahoo.co.jp>
Ivan Maidanski
2012-03-26 12:51:07 UTC
Permalink
Hi Kiyoshi,

I've just fixed this issue both in master and release branches. Please retry.

Regards.
Post by Kiyoshi KANAZAWA
Hello,
libatomic_ops/src/atomic_ops.h:197,
from ./include/private/gc_locks.h:30,
from ./include/private/gc_priv.h:85,
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:9:23: xmmintrin.h: No such file or directory
In file included from libatomic_ops/src/atomic_ops/sysdeps/gcc/x86_64.h:37,
from libatomic_ops/src/atomic_ops.h:197,
from ./include/private/gc_locks.h:30,
from ./include/private/gc_priv.h:85,
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:10: error: syntax error before "double_ptr_storage"
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:10: warning: data definition has no type or storage class
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:30: error: syntax error before "double_ptr_storage"
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:30: warning: no semicolon at end of struct or union
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:32: error: syntax error before '}' token
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:32: warning: data definition has no type or storage class
make[1]: *** [alloc.lo] Error 1
This occurs with gcc-3.4.3 & -m64 option.
Passes with gcc-4.4.7 & -m64.
I tried gc-7.2alpha6 but had the same result.
I'm afraid algorithm to find "GCC_PATH/lib/gcc/i386-pc-solaris-version/GCC_VERSION/install-tools/include" depends on gcc version.
gcc-3.4.3 is included in Solaris10 distribution.
Many GNU softwares, including gc, are required to build newer gcc.
(I once built them with -m32, and now trying with -m64)
Best regards,
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Ivan Maidanski
2012-03-26 15:10:07 UTC
Permalink
Hi Kiyoshi,

It is in Git repo: https://github.com/ivmai/bdwgc/

To test latest "release" candidate:

git clone git://github.com/ivmai/bdwgc.git -b release
cd bdwgc
git clone git://github.com/ivmai/libatomic_ops.git -b release
./configure
make check

Testing latest "development" version if a bit harder:

git clone git://github.com/ivmai/bdwgc.git
cd bdwgc
git clone git://github.com/ivmai/libatomic_ops.git
./autogen.sh
./configure
make check

Your you can get the modified file only: https://raw.github.com/ivmai/libatomic_ops/master/src/atomic_ops/sysdeps/standard_ao_double_t.h

Regards.
Hi, Ivan,
Thank you for quick response.
I do not where I can find it.
Will you send it to me via e-mail, as "diff -c" format or full replaced files, please ?
I'll check it asap.
Best regards,
Post by Ivan Maidanski
Hi Kiyoshi,
I've just fixed this issue both in master and release branches. Please retry.
Regards.
Post by Kiyoshi KANAZAWA
Hello,
libatomic_ops/src/atomic_ops.h:197,
                  from ./include/private/gc_locks.h:30,
                  from ./include/private/gc_priv.h:85,
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:9:23: xmmintrin.h: No such file or directory
In file included from libatomic_ops/src/atomic_ops/sysdeps/gcc/x86_64.h:37,
                  from libatomic_ops/src/atomic_ops.h:197,
                  from ./include/private/gc_locks.h:30,
                  from ./include/private/gc_priv.h:85,
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:10: error: syntax error before "double_ptr_storage"
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:10: warning: data definition has no type or storage class
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:30: error: syntax error before "double_ptr_storage"
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:30: warning: no semicolon at end of struct or union
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:32: error: syntax error before '}' token
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:32: warning: data definition has no type or storage class
make[1]: *** [alloc.lo] Error 1
This occurs with gcc-3.4.3 & -m64 option.
Passes with gcc-4.4.7 & -m64.
I tried gc-7.2alpha6 but had the same result.
I'm afraid algorithm to find "GCC_PATH/lib/gcc/i386-pc-solaris-version/GCC_VERSION/install-tools/include" depends on gcc version.
gcc-3.4.3 is included in Solaris10 distribution.
Many GNU softwares, including gc, are required to build newer gcc.
(I once built them with -m32, and now trying with -m64)
Best regards,
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Kiyoshi KANAZAWA
2012-03-26 15:59:40 UTC
Permalink
Hi, Ivan,

Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).

I'll learn about Git later.
It was not exist when I was working with MIT on X11 many years ago,
and now I have to use Windows software ;-<).

Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
It is in Git repo: https://github.com/ivmai/bdwgc/
git clone git://github.com/ivmai/bdwgc.git -b release
cd bdwgc
git clone git://github.com/ivmai/libatomic_ops.git -b release
./configure
make check
git clone git://github.com/ivmai/bdwgc.git
cd bdwgc
git clone git://github.com/ivmai/libatomic_ops.git
./autogen.sh
./configure
make check
Your you can get the modified file only: https://raw.github.com/ivmai/libatomic_ops/master/src/atomic_ops/sysdeps/standard_ao_double_t.h
Regards.
Hi, Ivan,
Thank you for quick response.
I do not where I can find it.
Will you send it to me via e-mail, as "diff -c" format or full replaced files, please ?
I'll check it asap.
Best regards,
Post by Ivan Maidanski
Hi Kiyoshi,
I've just fixed this issue both in master and release branches. Please retry.
Regards.
Post by Kiyoshi KANAZAWA
Hello,
libatomic_ops/src/atomic_ops.h:197,
                  from ./include/private/gc_locks.h:30,
                  from ./include/private/gc_priv.h:85,
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:9:23: xmmintrin.h: No such file or directory
In file included from libatomic_ops/src/atomic_ops/sysdeps/gcc/x86_64.h:37,
                  from libatomic_ops/src/atomic_ops.h:197,
                  from ./include/private/gc_locks.h:30,
                  from ./include/private/gc_priv.h:85,
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:10: error: syntax error before "double_ptr_storage"
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:10: warning: data definition has no type or storage class
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:30: error: syntax error before "double_ptr_storage"
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:30: warning: no semicolon at end of struct or union
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:32: error: syntax error before '}' token
libatomic_ops/src/atomic_ops/sysdeps/gcc/../standard_ao_double_t.h:32: warning: data definition has no type or storage class
make[1]: *** [alloc.lo] Error 1
This occurs with gcc-3.4.3 & -m64 option.
Passes with gcc-4.4.7 & -m64.
I tried gc-7.2alpha6 but had the same result.
I'm afraid algorithm to find "GCC_PATH/lib/gcc/i386-pc-solaris-version/GCC_VERSION/install-tools/include" depends on gcc version.
gcc-3.4.3 is included in Solaris10 distribution.
Many GNU softwares, including gc, are required to build newer gcc.
(I once built them with -m32, and now trying with -m64)
Best regards,
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Kiyoshi KANAZAWA
2012-03-26 21:27:04 UTC
Permalink
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)

--- Kiyoshi <***@yahoo.co.jp>
Ivan Maidanski
2012-03-27 07:05:30 UTC
Permalink
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
Would also be good if you test recent BDWGC/libatomic_ops snapshots instead of gc-7.1/7.2alpha6:

In case you don't use Git, to test the recent "release" branch snapshot (corresponding to 7.2 final candidate):

wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check

The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure

Regards.
Kiyoshi KANAZAWA
2012-03-27 14:53:27 UTC
Permalink
Hi, Ivan,

Done without Git.

(1) release
(1.1) suggestion
I guess it is better to set -DGC_THREADS for Solaris by default.
There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
Now, it is said in doc/README.solaris2 that
SOLARIS THREADS:
The collector must be compiled with -DGC_THREADS to be thread safe.
This assumes use of the pthread_ interface. Old style Solaris threads
are no longer supported.

(1.2) test result by gcc
make & make check passed with all the combination of
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)

(1.3) test result with Oracle cc
Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
make check fails (both -m32 & -m64).
It might be caused by some compile switces.
Error message is such as
libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3 .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o -L/usr/local/GNU/lib -ldl -lc -xarch=sse4_1 -m32
Undefined first referenced
symbol in file
GC_start_world .libs/alloc.o
GC_do_blocking_inner .libs/misc.o
GC_check_finalizer_nested .libs/finalize.o
GC_allocate_lock .libs/alloc.o
GC_reset_finalizer_nested .libs/finalize.o
GC_collecting .libs/alloc.o
GC_lock .libs/alloc.o
GC_push_thread_structures .libs/mark_rts.o
GC_push_all_stacks .libs/os_dep.o
GC_lock_holder .libs/finalize.o
GC_need_to_lock .libs/alloc.o
GC_thr_init .libs/misc.o
GC_stop_world .libs/alloc.o
ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
make[1]: *** [libgc.la] Error 2
make[1]: Target `all-am' not remade because of errors.
make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
make: *** [all-recursive] Error 1
make: Target `all' not remade because of errors.
make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'


(2) master
It is confusing.
make & make check passed with
(gcc-3.4.3, gcc-4.6.3, solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
and (gcc-4.4.7) (-m64),
but make check fails only with (gcc-4.4.7) (-m32).

libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
make[3]: Leaving directory `/tmp/ivmai-master/tests'
make check-TESTS
make[3]: Entering directory `/tmp/ivmai-master/tests'
/bin/bash: line 5: 16359 Segmentation Fault ${dir}$tst
FAIL: test_atomic
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded

I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
Post by Ivan Maidanski
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check
The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
Regards.
Ivan Maidanski
2012-03-28 10:27:24 UTC
Permalink
Hi Kiyoshi,
Hi, Ivan,
Done without Git.
(1) release
To be precise, you testing "release" branch of BDWGC (gc7.2) here.
(1.1) suggestion
I guess it is better to set -DGC_THREADS for Solaris by default.
There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
(i.e., now it does not mean that thr_ interface is used)
Now, it is said in doc/README.solaris2 that
The collector must be compiled with -DGC_THREADS to be thread safe.
This assumes use of the pthread_ interface. Old style Solaris threads
are no longer supported.
The doc is correct.
(1.2) test result by gcc
make & make check passed with all the combination of
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
(1.3) test result with Oracle cc
Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
make check fails (both -m32 & -m64).
It might be caused by some compile switches.
Error message is such as
libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3 .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o -L/usr/local/GNU/lib -ldl -lc -xarch=sse4_1 -m32
Undefined first referenced
symbol in file
GC_start_world .libs/alloc.o
..
ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
make[1]: *** [libgc.la] Error 2
make[1]: Target `all-am' not remade because of errors.
make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
make: *** [all-recursive] Error 1
make: Target `all' not remade because of errors.
make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
Please, if possible, investigate the problem with PTHREADS AM.
(2) master
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
What about "release" branch of it (is it working or the same problem, or has not been tested)?
It is confusing.
make & make check passed with
(gcc-3.4.3, gcc-4.6.3, solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
and (gcc-4.4.7) (-m64),
but make check fails only with (gcc-4.4.7) (-m32).
libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
make[3]: Leaving directory `/tmp/ivmai-master/tests'
make check-TESTS
make[3]: Entering directory `/tmp/ivmai-master/tests'
/bin/bash: line 5: 16359 Segmentation Fault ${dir}$tst
FAIL: test_atomic
Looks like a compiler bug. We could probably make a workaround
Could you please run it under gdb and tell me exact source line of Seg Fault?
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded
I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
Missing AO_XXX is normal.

Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check
The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
Regards.
Kiyoshi KANAZAWA
2012-03-28 12:05:09 UTC
Permalink
Hi, Ivan,

According to ChangeLog,
"release" is 7.2alpha6 + changes from 2011-06-15 to 2012-03-26.
"master" is [7.3alpha2] (development)
Post by Ivan Maidanski
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
is No. Later one.


(1) release
(1.1) suggestion
OK. I misunderstood as if GC_SOLARIS_THREADS and GC_THREADS were completely different.
(1.2) test result by gcc
Nothing to mention.
(1.3) test result with Oracle cc
I may try to make it conditional, but it needs time.
And I'm re-building all the NGU software I use. Much more time I need.

(2) master
Post by Ivan Maidanski
What about "release" branch of it (is it working or the same problem, or has not been tested)?
As mentioned in (1), no same problem in "release" branch.
I'll try gdb for "master" branch later.

By the way, it is written "Require automake 2.61 instead of v2.64." in [7.3alpha2] ChangeLog.
The latest version I can find is automake-1.11.3.
Do I need another one to test "master" branch ?

Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Done without Git.
(1) release
To be precise, you testing "release" branch of BDWGC (gc7.2) here.
(1.1) suggestion
I guess it is better to set -DGC_THREADS for Solaris by default.
There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
(i.e., now it does not mean that thr_ interface is used)
Now, it is said in doc/README.solaris2 that
   The collector must be compiled with -DGC_THREADS to be thread safe.
   This assumes use of the pthread_ interface.  Old style Solaris threads
   are no longer supported.
The doc is correct.
(1.2) test result by gcc
make & make check passed with all the combination of
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
(1.3) test result with Oracle cc
Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
make check fails (both -m32 & -m64).
It might be caused by some compile switches.
Error message is such as
libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o   -L/usr/local/GNU/lib -ldl -lc  -xarch=sse4_1 -m32 
Undefined                       first referenced
  symbol                             in file
GC_start_world                      .libs/alloc.o
..
ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
make[1]: *** [libgc.la] Error 2
make[1]: Target `all-am' not remade because of errors.
make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
make: *** [all-recursive] Error 1
make: Target `all' not remade because of errors.
make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
Please, if possible, investigate the problem with PTHREADS AM.
(2) master
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
What about "release" branch of it (is it working or the same problem, or has not been tested)?
It is confusing.
make & make check passed with
(gcc-3.4.3, gcc-4.6.3,  solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
and (gcc-4.4.7)  (-m64),
but make check fails only with (gcc-4.4.7) (-m32).
libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o  -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
make[3]: Leaving directory `/tmp/ivmai-master/tests'
make  check-TESTS
make[3]: Entering directory `/tmp/ivmai-master/tests'
/bin/bash: line 5: 16359 Segmentation Fault      ${dir}$tst
FAIL: test_atomic
Looks like a compiler bug. We could probably make a workaround
Could you please run it under gdb and tell me exact source line of Seg Fault?
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded
I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
Missing AO_XXX is normal.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check
The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
Regards.
Ivan Maidanski
2012-03-28 15:32:24 UTC
Permalink
Hi Kiyoshi,
Hi, Ivan,
According to ChangeLog,
"release" is 7.2alpha6 + changes from 2011-06-15 to 2012-03-26.
Yes, correct. This is 7.2 final release candidate (it is not released, so the version from release branch is 7.2alpha7 snapshot).
"master" is [7.3alpha2] (development)
This is 7.3alpha2 release candidate (again, it is not released, so the version from master branch is 7.3alpha1 snapshot).
Finally, on release, "development" word would be replaced with exact date.
Post by Ivan Maidanski
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
is No. Later one.
I've asked you because there 2 libs (bdwgc and libatomic_ops) and both have 2 versions planned for releasing (more stable 7.2 ("release" branch) and a development alpha 7.3 contained in "master" branch of Git repo). In the first case (1) you had reported about bdwgc-7.2 and in (2) you had reported about libatomic_ops-7.3alpha, it looked strange to me (why not to test to libs of the same version) - so I've asked you whether there were no problems with bdwgc-7.3alpha and libatomic_ops-7.2 or you just skipped their testing for now. (I'm really sorry for giving 2x2 libs in total to test and probably confusing you.)
(1) release
(1.1) suggestion
OK. I misunderstood as if GC_SOLARIS_THREADS and GC_THREADS were completely different.
(1.2) test result by gcc
Nothing to mention.
(1.3) test result with Oracle cc
I may try to make it conditional, but it needs time.
And I'm re-building all the NGU software I use. Much more time I need.
(2) master
Post by Ivan Maidanski
What about "release" branch of it (is it working or the same problem, or has not been tested)?
As mentioned in (1), no same problem in "release" branch.
My test Solaris environment is:
Solaris 10u9 x86
gcc version 3.4.6 (x86)
cc: Sun C 5.11 SunOS_i386 2010/08/13

I tested libatomic_ops (both release and master) with gcc, cc -m32, cc -m64. It succeeded.
I'll try gdb for "master" branch later.
By the way, it is written "Require automake 2.61 instead of v2.64." in [7.3alpha2] ChangeLog.
The latest version I can find is automake-1.11.3.
Thanks for spotting it - the correct is autoconf 2.61 (I'll change master ChangeLog in both bdwgc and libatomic_ops).
Do I need another one to test "master" branch ?
I've just improved -fPIC processing in configure (libatomic_ops in both release and master branches). As your reported you succeeded with libatomic_ops-7.2 but failed wit libatomic_ops-7.3alpha, I don't thing my recent commit fixes the bug in test_atomic on your side (but nonetheless, please try).
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Done without Git.
(1) release
To be precise, you testing "release" branch of BDWGC (gc7.2) here.
(1.1) suggestion
I guess it is better to set -DGC_THREADS for Solaris by default.
There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
(i.e., now it does not mean that thr_ interface is used)
Now, it is said in doc/README.solaris2 that
   The collector must be compiled with -DGC_THREADS to be thread safe.
   This assumes use of the pthread_ interface.  Old style Solaris threads
   are no longer supported.
The doc is correct.
(1.2) test result by gcc
make & make check passed with all the combination of
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
(1.3) test result with Oracle cc
Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
make check fails (both -m32 & -m64).
It might be caused by some compile switches.
Error message is such as
libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o   -L/usr/local/GNU/lib -ldl -lc  -xarch=sse4_1 -m32 
Undefined                       first referenced
  symbol                             in file
GC_start_world                      .libs/alloc.o
..
ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
make[1]: *** [libgc.la] Error 2
make[1]: Target `all-am' not remade because of errors.
make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
make: *** [all-recursive] Error 1
make: Target `all' not remade because of errors.
make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
Please, if possible, investigate the problem with PTHREADS AM.
(2) master
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
What about "release" branch of it (is it working or the same problem, or has not been tested)?
It is confusing.
make & make check passed with
(gcc-3.4.3, gcc-4.6.3,  solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
and (gcc-4.4.7)  (-m64),
but make check fails only with (gcc-4.4.7) (-m32).
libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o  -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
make[3]: Leaving directory `/tmp/ivmai-master/tests'
make  check-TESTS
make[3]: Entering directory `/tmp/ivmai-master/tests'
/bin/bash: line 5: 16359 Segmentation Fault      ${dir}$tst
FAIL: test_atomic
Looks like a compiler bug. We could probably make a workaround
Could you please run it under gdb and tell me exact source line of Seg Fault?
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded
I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
Missing AO_XXX is normal.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check
The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
Regards.
Ivan Maidanski
2012-03-28 16:33:07 UTC
Permalink
Hi Kiyoshi,

I've finally understand why do you fail with bdwgc if using Sun CC.

Here is how to invoke configure:
CC=cc CFLAGS="-xO3 ... -DGC_THREADS" ./configure
...
checking for thread model used by GCC... no
...
linking without pthread_support.o -> linkage error

This is wrong, the correct way is:
CC=cc CFLAGS="-xO3 ..." ./configure --enable-threads=posix

This is caused by the fact, that configure auto-detects threading model by parsing compiler output expecting the compiler is GCC, if it fails it assumes no MT support.

I've updated README.solaris2: https://github.com/ivmai/bdwgc/commit/cfca1cca99c757ac33c114ad3e9dd77ef430c0fa

PS. Still you have undiagnosed problem with libatomic_ops/master with gcc-4.4.7 -m32 on Solaris.

Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
According to ChangeLog,
"release" is 7.2alpha6 + changes from 2011-06-15 to 2012-03-26.
Yes, correct. This is 7.2 final release candidate (it is not released, so the version from release branch is 7.2alpha7 snapshot).
"master" is [7.3alpha2] (development)
This is 7.3alpha2 release candidate (again, it is not released, so the version from master branch is 7.3alpha1 snapshot).
Finally, on release, "development" word would be replaced with exact date.
Post by Ivan Maidanski
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
is No. Later one.
I've asked you because there 2 libs (bdwgc and libatomic_ops) and both have 2 versions planned for releasing (more stable 7.2 ("release" branch) and a development alpha 7.3 contained in "master" branch of Git repo). In the first case (1) you had reported about bdwgc-7.2 and in (2) you had reported about libatomic_ops-7.3alpha, it looked strange to me (why not to test to libs of the same version) - so I've asked you whether there were no problems with bdwgc-7.3alpha and libatomic_ops-7.2 or you just skipped their testing for now. (I'm really sorry for giving 2x2 libs in total to test and probably confusing you.)
(1) release
(1.1) suggestion
OK. I misunderstood as if GC_SOLARIS_THREADS and GC_THREADS were completely different.
(1.2) test result by gcc
Nothing to mention.
(1.3) test result with Oracle cc
I may try to make it conditional, but it needs time.
And I'm re-building all the NGU software I use. Much more time I need.
(2) master
Post by Ivan Maidanski
What about "release" branch of it (is it working or the same problem, or has not been tested)?
As mentioned in (1), no same problem in "release" branch.
Solaris 10u9 x86
gcc version 3.4.6 (x86)
cc: Sun C 5.11 SunOS_i386 2010/08/13
I tested libatomic_ops (both release and master) with gcc, cc -m32, cc -m64. It succeeded.
I'll try gdb for "master" branch later.
By the way, it is written "Require automake 2.61 instead of v2.64." in [7.3alpha2] ChangeLog.
The latest version I can find is automake-1.11.3.
Thanks for spotting it - the correct is autoconf 2.61 (I'll change master ChangeLog in both bdwgc and libatomic_ops).
Do I need another one to test "master" branch ?
I've just improved -fPIC processing in configure (libatomic_ops in both release and master branches). As your reported you succeeded with libatomic_ops-7.2 but failed wit libatomic_ops-7.3alpha, I don't thing my recent commit fixes the bug in test_atomic on your side (but nonetheless, please try).
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Done without Git.
(1) release
To be precise, you testing "release" branch of BDWGC (gc7.2) here.
(1.1) suggestion
I guess it is better to set -DGC_THREADS for Solaris by default.
There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
(i.e., now it does not mean that thr_ interface is used)
Now, it is said in doc/README.solaris2 that
   The collector must be compiled with -DGC_THREADS to be thread safe.
   This assumes use of the pthread_ interface.  Old style Solaris threads
   are no longer supported.
The doc is correct.
(1.2) test result by gcc
make & make check passed with all the combination of
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
(1.3) test result with Oracle cc
Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
make check fails (both -m32 & -m64).
It might be caused by some compile switches.
Error message is such as
libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o   -L/usr/local/GNU/lib -ldl -lc  -xarch=sse4_1 -m32 
Undefined                       first referenced
  symbol                             in file
GC_start_world                      .libs/alloc.o
..
ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
make[1]: *** [libgc.la] Error 2
make[1]: Target `all-am' not remade because of errors.
make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
make: *** [all-recursive] Error 1
make: Target `all' not remade because of errors.
make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
Please, if possible, investigate the problem with PTHREADS AM.
(2) master
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
What about "release" branch of it (is it working or the same problem, or has not been tested)?
It is confusing.
make & make check passed with
(gcc-3.4.3, gcc-4.6.3,  solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
and (gcc-4.4.7)  (-m64),
but make check fails only with (gcc-4.4.7) (-m32).
libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o  -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
make[3]: Leaving directory `/tmp/ivmai-master/tests'
make  check-TESTS
make[3]: Entering directory `/tmp/ivmai-master/tests'
/bin/bash: line 5: 16359 Segmentation Fault      ${dir}$tst
FAIL: test_atomic
Looks like a compiler bug. We could probably make a workaround
Could you please run it under gdb and tell me exact source line of Seg Fault?
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded
I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
Missing AO_XXX is normal.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check
The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
Regards.
Kiyoshi KANAZAWA
2012-03-28 22:32:34 UTC
Permalink
Hi, Ivan,

I checked "./configure --enable-threads=posix" with (Sun | Oracle) cc.
There is no problem now.

I did it in a hurry, taking breakfast, because it is related to the "release" version.
Check others later.

Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
I've finally understand why do you fail with bdwgc if using Sun CC.
CC=cc CFLAGS="-xO3 ... -DGC_THREADS" ./configure
...
checking for thread model used by GCC... no
...
linking without pthread_support.o -> linkage error
CC=cc CFLAGS="-xO3 ..." ./configure --enable-threads=posix
This is caused by the fact, that configure auto-detects threading model by parsing compiler output expecting the compiler is GCC, if it fails it assumes no MT support.
I've updated README.solaris2: https://github.com/ivmai/bdwgc/commit/cfca1cca99c757ac33c114ad3e9dd77ef430c0fa
PS. Still you have undiagnosed problem with libatomic_ops/master with gcc-4.4.7 -m32 on Solaris.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
According to ChangeLog,
"release" is 7.2alpha6 + changes from 2011-06-15 to 2012-03-26.
Yes, correct. This is 7.2 final release candidate (it is not released, so the version from release branch is 7.2alpha7 snapshot).
"master" is [7.3alpha2] (development)
This is 7.3alpha2 release candidate (again, it is not released, so the version from master branch is 7.3alpha1 snapshot).
Finally, on release, "development" word would be replaced with exact date.
Post by Ivan Maidanski
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
is No. Later one.
I've asked you because there 2 libs (bdwgc and libatomic_ops) and both have 2 versions planned for releasing (more stable 7.2 ("release" branch) and a development alpha 7.3 contained in "master" branch of Git repo). In the first case (1) you had reported about bdwgc-7.2 and in (2) you had reported about libatomic_ops-7.3alpha, it looked strange to me (why not to test to libs of the same version) - so I've asked you whether there were no problems with bdwgc-7.3alpha and libatomic_ops-7.2 or you just skipped their testing for now. (I'm really sorry for giving 2x2 libs in total to test and probably confusing you.)
(1) release
(1.1) suggestion
OK. I misunderstood as if GC_SOLARIS_THREADS and GC_THREADS were completely different.
(1.2) test result by gcc
Nothing to mention.
(1.3) test result with Oracle cc
I may try to make it conditional, but it needs time.
And I'm re-building all the NGU software I use. Much more time I need.
(2) master
Post by Ivan Maidanski
What about "release" branch of it (is it working or the same problem, or has not been tested)?
As mentioned in (1), no same problem in "release" branch.
Solaris 10u9 x86
gcc version 3.4.6 (x86)
cc: Sun C 5.11 SunOS_i386 2010/08/13
I tested libatomic_ops (both release and master) with gcc, cc -m32, cc -m64. It succeeded.
I'll try gdb for "master" branch later.
By the way, it is written  "Require automake 2.61 instead of v2.64." in [7.3alpha2] ChangeLog.
The latest version I can find is automake-1.11.3.
Thanks for spotting it - the correct is autoconf 2.61 (I'll change master ChangeLog in both bdwgc and libatomic_ops).
Do I need another one to test "master" branch ?
I've just improved -fPIC processing in configure (libatomic_ops in both release and master branches). As your reported you succeeded with libatomic_ops-7.2 but failed wit libatomic_ops-7.3alpha, I don't thing my recent commit fixes the bug in test_atomic on your side (but nonetheless, please try).
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Done without Git.
(1) release
To be precise, you testing "release" branch of BDWGC (gc7.2) here.
(1.1) suggestion
I guess it is better to set -DGC_THREADS for Solaris by default.
There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
(i.e., now it does not mean that thr_ interface is used)
Now, it is said in doc/README.solaris2 that
   The collector must be compiled with -DGC_THREADS to be thread safe.
   This assumes use of the pthread_ interface.  Old style Solaris threads
   are no longer supported.
The doc is correct.
(1.2) test result by gcc
make & make check passed with all the combination of
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
(1.3) test result with Oracle cc
Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
make check fails (both -m32 & -m64).
It might be caused by some compile switches.
Error message is such as
libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o   -L/usr/local/GNU/lib -ldl -lc  -xarch=sse4_1 -m32 
Undefined                       first referenced
  symbol                             in file
GC_start_world                      .libs/alloc.o
..
ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
make[1]: *** [libgc.la] Error 2
make[1]: Target `all-am' not remade because of errors.
make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
make: *** [all-recursive] Error 1
make: Target `all' not remade because of errors.
make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
Please, if possible, investigate the problem with PTHREADS AM.
(2) master
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
What about "release" branch of it (is it working or the same problem, or has not been tested)?
It is confusing.
make & make check passed with
(gcc-3.4.3, gcc-4.6.3,  solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
and (gcc-4.4.7)  (-m64),
but make check fails only with (gcc-4.4.7) (-m32).
libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o  -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
make[3]: Leaving directory `/tmp/ivmai-master/tests'
make  check-TESTS
make[3]: Entering directory `/tmp/ivmai-master/tests'
/bin/bash: line 5: 16359 Segmentation Fault      ${dir}$tst
FAIL: test_atomic
Looks like a compiler bug. We could probably make a workaround
Could you please run it under gdb and tell me exact source line of Seg Fault?
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded
I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
Missing AO_XXX is normal.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check
The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
Regards.
Kiyoshi KANAZAWA
2012-03-29 11:37:41 UTC
Permalink
Hi, Ivan,

About libatomic_ops/master with gcc-4.4.7 -m32:
Coredump seems to be caused by AO_compare_double_and_swap_double_full.
I used Sun dbx (gdb does not accept "ELF 32-bit" format produced by /usr/ccs/bin/ld).
% dbx test_atomic
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your .dbxrc
Reading test_atomic
Reading ld.so.1
Reading libpthread.so.1
Reading libc.so.1
(dbx) run
Running: test_atomic
(process id 29080)
***@1 (***@1) signal SEGV (no mapping at the fault address) in AO_compare_double_and_swap_double_full at line 193 in file "x86.h"
193 __asm__ __volatile__("xchg %%ebx,%6;" /* swap GOT ptr and new_val1 */

By the way, "master" branch does not require "--enable-threads=posix", right ?
./configure says "configure: WARNING: unrecognized options: --enable-threads"


I checked "release" branch with "./configure --enable-threads=posix" again.
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3, solarisstudio12.3, solstudio12.2), (-m32, -m64).
All the combination passed make & make check.

Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
I've finally understand why do you fail with bdwgc if using Sun CC.
CC=cc CFLAGS="-xO3 ... -DGC_THREADS" ./configure
...
checking for thread model used by GCC... no
...
linking without pthread_support.o -> linkage error
CC=cc CFLAGS="-xO3 ..." ./configure --enable-threads=posix
This is caused by the fact, that configure auto-detects threading model by parsing compiler output expecting the compiler is GCC, if it fails it assumes no MT support.
I've updated README.solaris2: https://github.com/ivmai/bdwgc/commit/cfca1cca99c757ac33c114ad3e9dd77ef430c0fa
PS. Still you have undiagnosed problem with libatomic_ops/master with gcc-4.4.7 -m32 on Solaris.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
According to ChangeLog,
"release" is 7.2alpha6 + changes from 2011-06-15 to 2012-03-26.
Yes, correct. This is 7.2 final release candidate (it is not released, so the version from release branch is 7.2alpha7 snapshot).
"master" is [7.3alpha2] (development)
This is 7.3alpha2 release candidate (again, it is not released, so the version from master branch is 7.3alpha1 snapshot).
Finally, on release, "development" word would be replaced with exact date.
Post by Ivan Maidanski
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
is No. Later one.
I've asked you because there 2 libs (bdwgc and libatomic_ops) and both have 2 versions planned for releasing (more stable 7.2 ("release" branch) and a development alpha 7.3 contained in "master" branch of Git repo). In the first case (1) you had reported about bdwgc-7.2 and in (2) you had reported about libatomic_ops-7.3alpha, it looked strange to me (why not to test to libs of the same version) - so I've asked you whether there were no problems with bdwgc-7.3alpha and libatomic_ops-7.2 or you just skipped their testing for now. (I'm really sorry for giving 2x2 libs in total to test and probably confusing you.)
(1) release
(1.1) suggestion
OK. I misunderstood as if GC_SOLARIS_THREADS and GC_THREADS were completely different.
(1.2) test result by gcc
Nothing to mention.
(1.3) test result with Oracle cc
I may try to make it conditional, but it needs time.
And I'm re-building all the NGU software I use. Much more time I need.
(2) master
Post by Ivan Maidanski
What about "release" branch of it (is it working or the same problem, or has not been tested)?
As mentioned in (1), no same problem in "release" branch.
Solaris 10u9 x86
gcc version 3.4.6 (x86)
cc: Sun C 5.11 SunOS_i386 2010/08/13
I tested libatomic_ops (both release and master) with gcc, cc -m32, cc -m64. It succeeded.
I'll try gdb for "master" branch later.
By the way, it is written  "Require automake 2.61 instead of v2.64." in [7.3alpha2] ChangeLog.
The latest version I can find is automake-1.11.3.
Thanks for spotting it - the correct is autoconf 2.61 (I'll change master ChangeLog in both bdwgc and libatomic_ops).
Do I need another one to test "master" branch ?
I've just improved -fPIC processing in configure (libatomic_ops in both release and master branches). As your reported you succeeded with libatomic_ops-7.2 but failed wit libatomic_ops-7.3alpha, I don't thing my recent commit fixes the bug in test_atomic on your side (but nonetheless, please try).
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Done without Git.
(1) release
To be precise, you testing "release" branch of BDWGC (gc7.2) here.
(1.1) suggestion
I guess it is better to set -DGC_THREADS for Solaris by default.
There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
(i.e., now it does not mean that thr_ interface is used)
Now, it is said in doc/README.solaris2 that
   The collector must be compiled with -DGC_THREADS to be thread safe.
   This assumes use of the pthread_ interface.  Old style Solaris threads
   are no longer supported.
The doc is correct.
(1.2) test result by gcc
make & make check passed with all the combination of
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
(1.3) test result with Oracle cc
Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
make check fails (both -m32 & -m64).
It might be caused by some compile switches.
Error message is such as
libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o   -L/usr/local/GNU/lib -ldl -lc  -xarch=sse4_1 -m32 
Undefined                       first referenced
  symbol                             in file
GC_start_world                      .libs/alloc.o
..
ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
make[1]: *** [libgc.la] Error 2
make[1]: Target `all-am' not remade because of errors.
make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
make: *** [all-recursive] Error 1
make: Target `all' not remade because of errors.
make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
Please, if possible, investigate the problem with PTHREADS AM.
(2) master
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
What about "release" branch of it (is it working or the same problem, or has not been tested)?
It is confusing.
make & make check passed with
(gcc-3.4.3, gcc-4.6.3,  solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
and (gcc-4.4.7)  (-m64),
but make check fails only with (gcc-4.4.7) (-m32).
libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o  -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
make[3]: Leaving directory `/tmp/ivmai-master/tests'
make  check-TESTS
make[3]: Entering directory `/tmp/ivmai-master/tests'
/bin/bash: line 5: 16359 Segmentation Fault      ${dir}$tst
FAIL: test_atomic
Looks like a compiler bug. We could probably make a workaround
Could you please run it under gdb and tell me exact source line of Seg Fault?
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded
I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
Missing AO_XXX is normal.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check
The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
Regards.
Ivan Maidanski
2012-03-29 13:46:24 UTC
Permalink
Hi Kiyoshi,
Hi, Ivan,
Coredump seems to be caused by AO_compare_double_and_swap_double_full.
I used Sun dbx (gdb does not accept "ELF 32-bit" format produced by /usr/ccs/bin/ld).
% dbx test_atomic
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your .dbxrc
Reading test_atomic
Reading ld.so.1
Reading libpthread.so.1
Reading libc.so.1
(dbx) run
Running: test_atomic
(process id 29080)
193 __asm__ __volatile__("xchg %%ebx,%6;" /* swap GOT ptr and new_val1 */
This means __PIC__ is defined. Please check whether test_atomic is compiled and linked with -fPIC option. (it should present). If not, check you're testing the most recent snapshot (i.e., configure.ac contains "AC_MSG_CHECKING(whether gcc -fPIC causes __PIC__ definition)" ).
Please check this.
By the way, "master" branch does not require "--enable-threads=posix", right ?
./configure says "configure: WARNING: unrecognized options: --enable-threads"
"master" branch of which library?
I guess you mean libatomic_ops library - it does not have such option (regardless of the branch you use - master or release) because it is meaningless without threads support.
I checked "release" branch with "./configure --enable-threads=posix" again.
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3, solarisstudio12.3, solstudio12.2), (-m32, -m64).
All the combination passed make & make check.
Yes, I understand that you have not problem with bdwgc/release but it would be good if you report me whether "master" branch of bdwgc is ok or not.

Let me list the commands for testing latest snapshot of "master" branch of BDWGC:

wget https://github.com/ivmai/bdwgc/zipball/master
unzip master
cd ivmai-bdwgc-*
wget https://github.com/ivmai/libatomic_ops/zipball/master
unzip master
mv ivmai-libatomic_ops-* libatomic_ops
./autogen.sh
./configure --enable-threads=posix
make check
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
I've finally understand why do you fail with bdwgc if using Sun CC.
CC=cc CFLAGS="-xO3 ... -DGC_THREADS" ./configure
...
checking for thread model used by GCC... no
...
linking without pthread_support.o -> linkage error
CC=cc CFLAGS="-xO3 ..." ./configure --enable-threads=posix
This is caused by the fact, that configure auto-detects threading model by parsing compiler output expecting the compiler is GCC, if it fails it assumes no MT support.
I've updated README.solaris2: https://github.com/ivmai/bdwgc/commit/cfca1cca99c757ac33c114ad3e9dd77ef430c0fa
PS. Still you have undiagnosed problem with libatomic_ops/master with gcc-4.4.7 -m32 on Solaris.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
According to ChangeLog,
"release" is 7.2alpha6 + changes from 2011-06-15 to 2012-03-26.
Yes, correct. This is 7.2 final release candidate (it is not released, so the version from release branch is 7.2alpha7 snapshot).
"master" is [7.3alpha2] (development)
This is 7.3alpha2 release candidate (again, it is not released, so the version from master branch is 7.3alpha1 snapshot).
Finally, on release, "development" word would be replaced with exact date.
Post by Ivan Maidanski
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
is No. Later one.
I've asked you because there 2 libs (bdwgc and libatomic_ops) and both have 2 versions planned for releasing (more stable 7.2 ("release" branch) and a development alpha 7.3 contained in "master" branch of Git repo). In the first case (1) you had reported about bdwgc-7.2 and in (2) you had reported about libatomic_ops-7.3alpha, it looked strange to me (why not to test to libs of the same version) - so I've asked you whether there were no problems with bdwgc-7.3alpha and libatomic_ops-7.2 or you just skipped their testing for now. (I'm really sorry for giving 2x2 libs in total to test and probably confusing you.)
(1) release
(1.1) suggestion
OK. I misunderstood as if GC_SOLARIS_THREADS and GC_THREADS were completely different.
(1.2) test result by gcc
Nothing to mention.
(1.3) test result with Oracle cc
I may try to make it conditional, but it needs time.
And I'm re-building all the NGU software I use. Much more time I need.
(2) master
Post by Ivan Maidanski
What about "release" branch of it (is it working or the same problem, or has not been tested)?
As mentioned in (1), no same problem in "release" branch.
Solaris 10u9 x86
gcc version 3.4.6 (x86)
cc: Sun C 5.11 SunOS_i386 2010/08/13
I tested libatomic_ops (both release and master) with gcc, cc -m32, cc -m64. It succeeded.
I'll try gdb for "master" branch later.
By the way, it is written  "Require automake 2.61 instead of v2.64." in [7.3alpha2] ChangeLog.
The latest version I can find is automake-1.11.3.
Thanks for spotting it - the correct is autoconf 2.61 (I'll change master ChangeLog in both bdwgc and libatomic_ops).
Do I need another one to test "master" branch ?
I've just improved -fPIC processing in configure (libatomic_ops in both release and master branches). As your reported you succeeded with libatomic_ops-7.2 but failed wit libatomic_ops-7.3alpha, I don't thing my recent commit fixes the bug in test_atomic on your side (but nonetheless, please try).
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Done without Git.
(1) release
To be precise, you testing "release" branch of BDWGC (gc7.2) here.
(1.1) suggestion
I guess it is better to set -DGC_THREADS for Solaris by default.
There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
(i.e., now it does not mean that thr_ interface is used)
Now, it is said in doc/README.solaris2 that
   The collector must be compiled with -DGC_THREADS to be thread safe.
   This assumes use of the pthread_ interface.  Old style Solaris threads
   are no longer supported.
The doc is correct.
(1.2) test result by gcc
make & make check passed with all the combination of
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
(1.3) test result with Oracle cc
Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
make check fails (both -m32 & -m64).
It might be caused by some compile switches.
Error message is such as
libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o   -L/usr/local/GNU/lib -ldl -lc  -xarch=sse4_1 -m32 
Undefined                       first referenced
  symbol                             in file
GC_start_world                      .libs/alloc.o
..
ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
make[1]: *** [libgc.la] Error 2
make[1]: Target `all-am' not remade because of errors.
make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
make: *** [all-recursive] Error 1
make: Target `all' not remade because of errors.
make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
Please, if possible, investigate the problem with PTHREADS AM.
(2) master
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
What about "release" branch of it (is it working or the same problem, or has not been tested)?
It is confusing.
make & make check passed with
(gcc-3.4.3, gcc-4.6.3,  solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
and (gcc-4.4.7)  (-m64),
but make check fails only with (gcc-4.4.7) (-m32).
libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o  -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
make[3]: Leaving directory `/tmp/ivmai-master/tests'
make  check-TESTS
make[3]: Entering directory `/tmp/ivmai-master/tests'
/bin/bash: line 5: 16359 Segmentation Fault      ${dir}$tst
FAIL: test_atomic
Looks like a compiler bug. We could probably make a workaround
Could you please run it under gdb and tell me exact source line of Seg Fault?
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded
I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
Missing AO_XXX is normal.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check
The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
Regards.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Kiyoshi KANAZAWA
2012-03-29 14:53:04 UTC
Permalink
Hi, Ivan,

Yes, you are right.
-D__PIC__=1 is defined and -fPIC is not specifyed.
I noticed my error.
I'm afraid I got bdwgc-master but unzipped bdwgc-release.

Downloaded the latest one again as follows:
% wget --no-check-certificate https://github.com/ivmai/bdwgc/zipball/master
% unzip master
% cd ivmai-bdwgc-cfca1cc
% wget --no-check-certificate https://github.com/ivmai/libatomic_ops/zipball/master
% unzip master
% mv ivmai-libatomic_ops-531888d libatomic_ops
% ./autogen.sh

Made a tar-ball of this directory once, and took out files from the tar-ball for every test.
configured such as
./configure --enable-threads=posix CC=cc -m32.

make & make check pass with -m64, but make check failes with -m32,
independent of (cc, gcc-VERSION).

Results of make check is:
PASS: cordtest
ld.so.1: gctest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/gctest: symbol GC_get_version: referenced symbol not found
/bin/bash: line 5: 23352 Killed ${dir}$tst
FAIL: gctest
ld.so.1: leaktest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/leaktest: symbol GC_set_find_leak: referenced symbol not found
/bin/bash: line 5: 23370 Killed ${dir}$tst
FAIL: leaktest
ld.so.1: middletest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/middletest: symbol GC_set_all_interior_pointers: referenced symbol not found
/bin/bash: line 5: 23388 Killed ${dir}$tst
FAIL: middletest
GC_check_heap_block: found smashed heap objects:
:
PASS: smashtest
ld.so.1: hugetest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/hugetest: symbol GC_ignore_warn_proc: referenced symbol not found
/bin/bash: line 5: 23422 Killed ${dir}$tst
FAIL: hugetest
Heap size: 65536
Heap size: 131072
PASS: realloc_test
ld.so.1: staticrootstest: fatal: libstaticrootslib.so.1: open failed: No such file or directory
/bin/bash: line 5: 23456 Killed ${dir}$tst
FAIL: staticrootstest
ld.so.1: threadleaktest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/threadleaktest: symbol GC_set_find_leak: referenced symbol not found
/bin/bash: line 5: 23474 Killed ${dir}$tst
FAIL: threadleaktest
threadkey_test skipped
PASS: threadkey_test
subthread_create: created 207 threads (207 ended)
PASS: subthread_create
/bin/bash: line 5: 23524 Segmentation Fault ${dir}$tst
FAIL: initsecondarythread
ld.so.1: disclaim_test: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/disclaim_test: symbol GC_set_all_interior_pointers: referenced symbol not found
/bin/bash: line 5: 23542 Killed ${dir}$tst
FAIL: disclaim_test
ld.so.1: disclaim_bench: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/disclaim_bench: symbol GC_init_finalized_malloc: referenced symbol not found
/bin/bash: line 5: 23560 Killed ${dir}$tst
FAIL: disclaim_bench
====================================
9 of 14 tests failed
Please report to ***@linux.hpl.hp.com
====================================

Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Coredump seems to be caused by AO_compare_double_and_swap_double_full.
I used Sun dbx (gdb does not accept "ELF 32-bit" format produced by /usr/ccs/bin/ld).
% dbx test_atomic
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your .dbxrc
Reading test_atomic
Reading ld.so.1
Reading libpthread.so.1
Reading libc.so.1
(dbx) run                                                                   
Running: test_atomic
(process id 29080)
   193     __asm__ __volatile__("xchg %%ebx,%6;" /* swap GOT ptr and new_val1 */
This means __PIC__ is defined. Please check whether test_atomic is compiled and linked with -fPIC option. (it should present). If not, check you're testing the most recent snapshot (i.e., configure.ac contains "AC_MSG_CHECKING(whether gcc -fPIC causes __PIC__ definition)" ).
Please check this.
By the way, "master" branch does not require "--enable-threads=posix", right ?
./configure says "configure: WARNING: unrecognized options: --enable-threads"
"master" branch of which library?
I guess you mean libatomic_ops library - it does not have such option (regardless of the branch you use - master or release) because it is meaningless without threads support.
I checked "release" branch with "./configure --enable-threads=posix" again.
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3, solarisstudio12.3, solstudio12.2), (-m32, -m64).
All the combination passed make & make check.
Yes, I understand that you have not problem with bdwgc/release but it would be good if you report me whether "master" branch of bdwgc is ok or not.
wget https://github.com/ivmai/bdwgc/zipball/master
unzip master
cd ivmai-bdwgc-*
wget https://github.com/ivmai/libatomic_ops/zipball/master
unzip master
mv ivmai-libatomic_ops-* libatomic_ops
./autogen.sh
./configure --enable-threads=posix
make check
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
I've finally understand why do you fail with bdwgc if using Sun CC.
CC=cc CFLAGS="-xO3 ... -DGC_THREADS" ./configure
...
checking for thread model used by GCC... no
...
linking without pthread_support.o -> linkage error
CC=cc CFLAGS="-xO3 ..." ./configure --enable-threads=posix
This is caused by the fact, that configure auto-detects threading model by parsing compiler output expecting the compiler is GCC, if it fails it assumes no MT support.
I've updated README.solaris2: https://github.com/ivmai/bdwgc/commit/cfca1cca99c757ac33c114ad3e9dd77ef430c0fa
PS. Still you have undiagnosed problem with libatomic_ops/master with gcc-4.4.7 -m32 on Solaris.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
According to ChangeLog,
"release" is 7.2alpha6 + changes from 2011-06-15 to 2012-03-26.
Yes, correct. This is 7.2 final release candidate (it is not released, so the version from release branch is 7.2alpha7 snapshot).
"master" is [7.3alpha2] (development)
This is 7.3alpha2 release candidate (again, it is not released, so the version from master branch is 7.3alpha1 snapshot).
Finally, on release, "development" word would be replaced with exact date.
Post by Ivan Maidanski
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
is No. Later one.
I've asked you because there 2 libs (bdwgc and libatomic_ops) and both have 2 versions planned for releasing (more stable 7.2 ("release" branch) and a development alpha 7.3 contained in "master" branch of Git repo). In the first case (1) you had reported about bdwgc-7.2 and in (2) you had reported about libatomic_ops-7.3alpha, it looked strange to me (why not to test to libs of the same version) - so I've asked you whether there were no problems with bdwgc-7.3alpha and libatomic_ops-7.2 or you just skipped their testing for now. (I'm really sorry for giving 2x2 libs in total to test and probably confusing you.)
(1) release
(1.1) suggestion
OK. I misunderstood as if GC_SOLARIS_THREADS and GC_THREADS were completely different.
(1.2) test result by gcc
Nothing to mention.
(1.3) test result with Oracle cc
I may try to make it conditional, but it needs time.
And I'm re-building all the NGU software I use. Much more time I need.
(2) master
Post by Ivan Maidanski
What about "release" branch of it (is it working or the same problem, or has not been tested)?
As mentioned in (1), no same problem in "release" branch.
Solaris 10u9 x86
gcc version 3.4.6 (x86)
cc: Sun C 5.11 SunOS_i386 2010/08/13
I tested libatomic_ops (both release and master) with gcc, cc -m32, cc -m64. It succeeded.
I'll try gdb for "master" branch later.
By the way, it is written  "Require automake 2.61 instead of v2.64." in [7.3alpha2] ChangeLog.
The latest version I can find is automake-1.11.3.
Thanks for spotting it - the correct is autoconf 2.61 (I'll change master ChangeLog in both bdwgc and libatomic_ops).
Do I need another one to test "master" branch ?
I've just improved -fPIC processing in configure (libatomic_ops in both release and master branches). As your reported you succeeded with libatomic_ops-7.2 but failed wit libatomic_ops-7.3alpha, I don't thing my recent commit fixes the bug in test_atomic on your side (but nonetheless, please try).
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Done without Git.
(1) release
To be precise, you testing "release" branch of BDWGC (gc7.2) here.
(1.1) suggestion
I guess it is better to set -DGC_THREADS for Solaris by default.
There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
(i.e., now it does not mean that thr_ interface is used)
Now, it is said in doc/README.solaris2 that
   The collector must be compiled with -DGC_THREADS to be thread safe.
   This assumes use of the pthread_ interface.  Old style Solaris threads
   are no longer supported.
The doc is correct.
(1.2) test result by gcc
make & make check passed with all the combination of
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
(1.3) test result with Oracle cc
Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
make check fails (both -m32 & -m64).
It might be caused by some compile switches.
Error message is such as
libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o   -L/usr/local/GNU/lib -ldl -lc  -xarch=sse4_1 -m32 
Undefined                       first referenced
  symbol                             in file
GC_start_world                      .libs/alloc.o
..
ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
make[1]: *** [libgc.la] Error 2
make[1]: Target `all-am' not remade because of errors.
make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
make: *** [all-recursive] Error 1
make: Target `all' not remade because of errors.
make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
Please, if possible, investigate the problem with PTHREADS AM.
(2) master
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
What about "release" branch of it (is it working or the same problem, or has not been tested)?
It is confusing.
make & make check passed with
(gcc-3.4.3, gcc-4.6.3,  solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
and (gcc-4.4.7)  (-m64),
but make check fails only with (gcc-4.4.7) (-m32).
libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o  -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
make[3]: Leaving directory `/tmp/ivmai-master/tests'
make  check-TESTS
make[3]: Entering directory `/tmp/ivmai-master/tests'
/bin/bash: line 5: 16359 Segmentation Fault      ${dir}$tst
FAIL: test_atomic
Looks like a compiler bug. We could probably make a workaround
Could you please run it under gdb and tell me exact source line of Seg Fault?
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded
I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
Missing AO_XXX is normal.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check
The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
Regards.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Ivan Maidanski
2012-03-29 15:18:03 UTC
Permalink
Hi Kiyoshi,
Hi, Ivan,
Yes, you are right.
-D__PIC__=1 is defined and -fPIC is not specified.
I noticed my error.
So, just to confirm, now you don't have the problem with libatomic_ops compiled by gcc-4.4.7 -m32, correct?
I'm afraid I got bdwgc-master but unzipped bdwgc-release.
% wget --no-check-certificate https://github.com/ivmai/bdwgc/zipball/master
% unzip master
% cd ivmai-bdwgc-cfca1cc
% wget --no-check-certificate https://github.com/ivmai/libatomic_ops/zipball/master
% unzip master
% mv ivmai-libatomic_ops-531888d libatomic_ops
% ./autogen.sh
Made a tar-ball of this directory once, and took out files from the tar-ball for every test.
configured such as
./configure --enable-threads=posix CC=cc -m32.
make & make check pass with -m64, but make check fails with -m32,
independent of (cc, gcc-VERSION).
PASS: cordtest
ld.so.1: gctest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/gctest: symbol GC_get_version: referenced symbol not found
/bin/bash: line 5: 23352 Killed ${dir}$tst
FAIL: gctest
ld.so.1: leaktest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/leaktest: symbol GC_set_find_leak: referenced symbol not found
/bin/bash: line 5: 23370 Killed ${dir}$tst
FAIL: leaktest
...
====================================
9 of 14 tests failed
====================================
It looks like you have already installed old gc7.1 (m32) shared library on your host and trying gc7.2 (or gc7.3) tests (linked against shared libgc.so) - of course they will fail because they use some symbols not offered by old libgc.so (v7.1).

Please do "make uninstall" (or make install) before make check.

Regards.
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Coredump seems to be caused by AO_compare_double_and_swap_double_full.
I used Sun dbx (gdb does not accept "ELF 32-bit" format produced by /usr/ccs/bin/ld).
% dbx test_atomic
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your .dbxrc
Reading test_atomic
Reading ld.so.1
Reading libpthread.so.1
Reading libc.so.1
(dbx) run                                                                   
Running: test_atomic
(process id 29080)
   193     __asm__ __volatile__("xchg %%ebx,%6;" /* swap GOT ptr and new_val1 */
This means __PIC__ is defined. Please check whether test_atomic is compiled and linked with -fPIC option. (it should present). If not, check you're testing the most recent snapshot (i.e., configure.ac contains "AC_MSG_CHECKING(whether gcc -fPIC causes __PIC__ definition)" ).
Please check this.
By the way, "master" branch does not require "--enable-threads=posix", right ?
./configure says "configure: WARNING: unrecognized options: --enable-threads"
"master" branch of which library?
I guess you mean libatomic_ops library - it does not have such option (regardless of the branch you use - master or release) because it is meaningless without threads support.
I checked "release" branch with "./configure --enable-threads=posix" again.
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3, solarisstudio12.3, solstudio12.2), (-m32, -m64).
All the combination passed make & make check.
Yes, I understand that you have not problem with bdwgc/release but it would be good if you report me whether "master" branch of bdwgc is ok or not.
wget https://github.com/ivmai/bdwgc/zipball/master
unzip master
cd ivmai-bdwgc-*
wget https://github.com/ivmai/libatomic_ops/zipball/master
unzip master
mv ivmai-libatomic_ops-* libatomic_ops
./autogen.sh
./configure --enable-threads=posix
make check
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
I've finally understand why do you fail with bdwgc if using Sun CC.
CC=cc CFLAGS="-xO3 ... -DGC_THREADS" ./configure
...
checking for thread model used by GCC... no
...
linking without pthread_support.o -> linkage error
CC=cc CFLAGS="-xO3 ..." ./configure --enable-threads=posix
This is caused by the fact, that configure auto-detects threading model by parsing compiler output expecting the compiler is GCC, if it fails it assumes no MT support.
I've updated README.solaris2: https://github.com/ivmai/bdwgc/commit/cfca1cca99c757ac33c114ad3e9dd77ef430c0fa
PS. Still you have undiagnosed problem with libatomic_ops/master with gcc-4.4.7 -m32 on Solaris.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
According to ChangeLog,
"release" is 7.2alpha6 + changes from 2011-06-15 to 2012-03-26.
Yes, correct. This is 7.2 final release candidate (it is not released, so the version from release branch is 7.2alpha7 snapshot).
"master" is [7.3alpha2] (development)
This is 7.3alpha2 release candidate (again, it is not released, so the version from master branch is 7.3alpha1 snapshot).
Finally, on release, "development" word would be replaced with exact date.
Post by Ivan Maidanski
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
is No. Later one.
I've asked you because there 2 libs (bdwgc and libatomic_ops) and both have 2 versions planned for releasing (more stable 7.2 ("release" branch) and a development alpha 7.3 contained in "master" branch of Git repo). In the first case (1) you had reported about bdwgc-7.2 and in (2) you had reported about libatomic_ops-7.3alpha, it looked strange to me (why not to test to libs of the same version) - so I've asked you whether there were no problems with bdwgc-7.3alpha and libatomic_ops-7.2 or you just skipped their testing for now. (I'm really sorry for giving 2x2 libs in total to test and probably confusing you.)
(1) release
(1.1) suggestion
OK. I misunderstood as if GC_SOLARIS_THREADS and GC_THREADS were completely different.
(1.2) test result by gcc
Nothing to mention.
(1.3) test result with Oracle cc
I may try to make it conditional, but it needs time.
And I'm re-building all the NGU software I use. Much more time I need.
(2) master
Post by Ivan Maidanski
What about "release" branch of it (is it working or the same problem, or has not been tested)?
As mentioned in (1), no same problem in "release" branch.
Solaris 10u9 x86
gcc version 3.4.6 (x86)
cc: Sun C 5.11 SunOS_i386 2010/08/13
I tested libatomic_ops (both release and master) with gcc, cc -m32, cc -m64. It succeeded.
I'll try gdb for "master" branch later.
By the way, it is written  "Require automake 2.61 instead of v2.64." in [7.3alpha2] ChangeLog.
The latest version I can find is automake-1.11.3.
Thanks for spotting it - the correct is autoconf 2.61 (I'll change master ChangeLog in both bdwgc and libatomic_ops).
Do I need another one to test "master" branch ?
I've just improved -fPIC processing in configure (libatomic_ops in both release and master branches). As your reported you succeeded with libatomic_ops-7.2 but failed wit libatomic_ops-7.3alpha, I don't thing my recent commit fixes the bug in test_atomic on your side (but nonetheless, please try).
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Done without Git.
(1) release
To be precise, you testing "release" branch of BDWGC (gc7.2) here.
(1.1) suggestion
I guess it is better to set -DGC_THREADS for Solaris by default.
There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
(i.e., now it does not mean that thr_ interface is used)
Now, it is said in doc/README.solaris2 that
   The collector must be compiled with -DGC_THREADS to be thread safe.
   This assumes use of the pthread_ interface.  Old style Solaris threads
   are no longer supported.
The doc is correct.
(1.2) test result by gcc
make & make check passed with all the combination of
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
(1.3) test result with Oracle cc
Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
make check fails (both -m32 & -m64).
It might be caused by some compile switches.
Error message is such as
libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o   -L/usr/local/GNU/lib -ldl -lc  -xarch=sse4_1 -m32 
Undefined                       first referenced
  symbol                             in file
GC_start_world                      .libs/alloc.o
..
ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
make[1]: *** [libgc.la] Error 2
make[1]: Target `all-am' not remade because of errors.
make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
make: *** [all-recursive] Error 1
make: Target `all' not remade because of errors.
make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
Please, if possible, investigate the problem with PTHREADS AM.
(2) master
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
What about "release" branch of it (is it working or the same problem, or has not been tested)?
It is confusing.
make & make check passed with
(gcc-3.4.3, gcc-4.6.3,  solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
and (gcc-4.4.7)  (-m64),
but make check fails only with (gcc-4.4.7) (-m32).
libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o  -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
make[3]: Leaving directory `/tmp/ivmai-master/tests'
make  check-TESTS
make[3]: Entering directory `/tmp/ivmai-master/tests'
/bin/bash: line 5: 16359 Segmentation Fault      ${dir}$tst
FAIL: test_atomic
Looks like a compiler bug. We could probably make a workaround
Could you please run it under gdb and tell me exact source line of Seg Fault?
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded
I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
Missing AO_XXX is normal.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check
The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
Regards.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Kiyoshi KANAZAWA
2012-03-30 11:49:13 UTC
Permalink
Hi, Ivan,

I don't have the problem with libatomic_ops compiled by gcc-4.4.7 -m32.
Everything cleared on "release" branch.


I checked "master" release without installing gc-7.1.
Make & make check passed (All 14 tests passed) with gcc:
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
under the condition that "-R($TOPDIR)/.libs" specifyed.
Without "-R($TOPDIR)/.libs", make check failed:
make check-TESTS
make[2]: Entering directory `/tmp/ivmai-bdwgc-cfca1cc'
ld.so.1: cordtest: fatal: libgc.so.1: open failed: No such file or directory
/bin/bash: line 5: 1941 Killed ${dir}$tst
FAIL: cordtest
(many other tests failed with the same message.)

With Oracle cc, make check failed event if I specifyed "-R($TOPDIR)/.libs":
make check-TESTS
make[2]: Entering directory `/tmp/ivmai-bdwgc-cfca1cc'
ld.so.1: cordtest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/: symbol GC_init: referenced symbol not found
/bin/bash: line 5: 19437 Killed ${dir}$tst
FAIL: cordtest
(many other tests failed with the same message.)
May be it is because solarisstudio12.3 & solstudio12.2, updated version of SUNWspro, has its own libgc.so.
With LD_LIBRARY_PATH who has no path to solarisstudio12.3 & solstudio12.2, make & make check passed.
(I remove these pathes when I install softwares with gcc.)
But it is not good for (Sun|Oracle) cc users.

I hope "make check" will link libgc.so in its own directory without -R, and independent of LD_LIBRARY_PATH.
This is the only thing I want to mention about "master" branch.
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Yes, you are right.
-D__PIC__=1 is defined and -fPIC is not specified.
I noticed my error.
So, just to confirm, now you don't have the problem with libatomic_ops compiled by gcc-4.4.7 -m32, correct?
I'm afraid I got bdwgc-master but unzipped bdwgc-release.
% wget --no-check-certificate https://github.com/ivmai/bdwgc/zipball/master
% unzip master
% cd ivmai-bdwgc-cfca1cc
% wget --no-check-certificate https://github.com/ivmai/libatomic_ops/zipball/master
% unzip master
% mv ivmai-libatomic_ops-531888d libatomic_ops
% ./autogen.sh
Made a tar-ball of this directory once, and took out files from the tar-ball for every test.
configured such as
./configure --enable-threads=posix CC=cc -m32.
make & make check pass with -m64, but make check fails with -m32,
independent of (cc, gcc-VERSION).
PASS: cordtest
ld.so.1: gctest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/gctest: symbol GC_get_version: referenced symbol not found
/bin/bash: line 5: 23352 Killed                  ${dir}$tst
FAIL: gctest
ld.so.1: leaktest: fatal: relocation error: file /tmp/ivmai-bdwgc-cfca1cc/.libs/leaktest: symbol GC_set_find_leak: referenced symbol not found
/bin/bash: line 5: 23370 Killed                  ${dir}$tst
FAIL: leaktest
...
====================================
9 of 14 tests failed
====================================
It looks like you have already installed old gc7.1 (m32) shared library on your host and trying gc7.2 (or gc7.3) tests (linked against shared libgc.so) - of course they will fail because they use some symbols not offered by old libgc.so (v7.1).
Please do "make uninstall" (or make install) before make check.
Regards.
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Coredump seems to be caused by AO_compare_double_and_swap_double_full.
I used Sun dbx (gdb does not accept "ELF 32-bit" format produced by /usr/ccs/bin/ld).
% dbx test_atomic
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.9' in your .dbxrc
Reading test_atomic
Reading ld.so.1
Reading libpthread.so.1
Reading libc.so.1
(dbx) run                                                                   
Running: test_atomic
(process id 29080)
   193     __asm__ __volatile__("xchg %%ebx,%6;" /* swap GOT ptr and new_val1 */
This means __PIC__ is defined. Please check whether test_atomic is compiled and linked with -fPIC option. (it should present). If not, check you're testing the most recent snapshot (i.e., configure.ac contains "AC_MSG_CHECKING(whether gcc -fPIC causes __PIC__ definition)" ).
Please check this.
By the way, "master" branch does not require "--enable-threads=posix", right ?
./configure says "configure: WARNING: unrecognized options: --enable-threads"
"master" branch of which library?
I guess you mean libatomic_ops library - it does not have such option (regardless of the branch you use - master or release) because it is meaningless without threads support.
I checked "release" branch with "./configure --enable-threads=posix" again.
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3, solarisstudio12.3, solstudio12.2), (-m32, -m64).
All the combination passed make & make check.
Yes, I understand that you have not problem with bdwgc/release but it would be good if you report me whether "master" branch of bdwgc is ok or not.
wget https://github.com/ivmai/bdwgc/zipball/master
unzip master
cd ivmai-bdwgc-*
wget https://github.com/ivmai/libatomic_ops/zipball/master
unzip master
mv ivmai-libatomic_ops-* libatomic_ops
./autogen.sh
./configure --enable-threads=posix
make check
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
I've finally understand why do you fail with bdwgc if using Sun CC.
CC=cc CFLAGS="-xO3 ... -DGC_THREADS" ./configure
...
checking for thread model used by GCC... no
...
linking without pthread_support.o -> linkage error
CC=cc CFLAGS="-xO3 ..." ./configure --enable-threads=posix
This is caused by the fact, that configure auto-detects threading model by parsing compiler output expecting the compiler is GCC, if it fails it assumes no MT support.
I've updated README.solaris2: https://github.com/ivmai/bdwgc/commit/cfca1cca99c757ac33c114ad3e9dd77ef430c0fa
PS. Still you have undiagnosed problem with libatomic_ops/master with gcc-4.4.7 -m32 on Solaris.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
According to ChangeLog,
"release" is 7.2alpha6 + changes from 2011-06-15 to 2012-03-26.
Yes, correct. This is 7.2 final release candidate (it is not released, so the version from release branch is 7.2alpha7 snapshot).
"master" is [7.3alpha2] (development)
This is 7.3alpha2 release candidate (again, it is not released, so the version from master branch is 7.3alpha1 snapshot).
Finally, on release, "development" word would be replaced with exact date.
Post by Ivan Maidanski
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
is No. Later one.
I've asked you because there 2 libs (bdwgc and libatomic_ops) and both have 2 versions planned for releasing (more stable 7.2 ("release" branch) and a development alpha 7.3 contained in "master" branch of Git repo). In the first case (1) you had reported about bdwgc-7.2 and in (2) you had reported about libatomic_ops-7.3alpha, it looked strange to me (why not to test to libs of the same version) - so I've asked you whether there were no problems with bdwgc-7.3alpha and libatomic_ops-7.2 or you just skipped their testing for now. (I'm really sorry for giving 2x2 libs in total to test and probably confusing you.)
(1) release
(1.1) suggestion
OK. I misunderstood as if GC_SOLARIS_THREADS and GC_THREADS were completely different.
(1.2) test result by gcc
Nothing to mention.
(1.3) test result with Oracle cc
I may try to make it conditional, but it needs time.
And I'm re-building all the NGU software I use. Much more time I need.
(2) master
Post by Ivan Maidanski
What about "release" branch of it (is it working or the same problem, or has not been tested)?
As mentioned in (1), no same problem in "release" branch.
Solaris 10u9 x86
gcc version 3.4.6 (x86)
cc: Sun C 5.11 SunOS_i386 2010/08/13
I tested libatomic_ops (both release and master) with gcc, cc -m32, cc -m64. It succeeded.
I'll try gdb for "master" branch later.
By the way, it is written  "Require automake 2.61 instead of v2.64." in [7.3alpha2] ChangeLog.
The latest version I can find is automake-1.11.3.
Thanks for spotting it - the correct is autoconf 2.61 (I'll change master ChangeLog in both bdwgc and libatomic_ops).
Do I need another one to test "master" branch ?
I've just improved -fPIC processing in configure (libatomic_ops in both release and master branches). As your reported you succeeded with libatomic_ops-7.2 but failed wit libatomic_ops-7.3alpha, I don't thing my recent commit fixes the bug in test_atomic on your side (but nonetheless, please try).
Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
Done without Git.
(1) release
To be precise, you testing "release" branch of BDWGC (gc7.2) here.
(1.1) suggestion
I guess it is better to set -DGC_THREADS for Solaris by default.
There was choice -DGC_SOLARIS_THREADS (thr_ functions) or -DGC_THREADS in gc-7.1.
No, GC_SOLARIS_THREADS is a synonym of GC_THREADS on Solaris.
(i.e., now it does not mean that thr_ interface is used)
Now, it is said in doc/README.solaris2 that
   The collector must be compiled with -DGC_THREADS to be thread safe.
   This assumes use of the pthread_ interface.  Old style Solaris threads
   are no longer supported.
The doc is correct.
(1.2) test result by gcc
make & make check passed with all the combination of
(gcc-3.4.3, gcc-4.4.7, gcc-4.6.3) (-m32, -m64)
(1.3) test result with Oracle cc
Tried also Oracle cc (solstudio12.2, solarisstudio12.3), and found
make check fails (both -m32 & -m64).
It might be caused by some compile switches.
Error message is such as
libtool: link: cc -I/tmp/ivmai-bdwgc-aee0d2b -xarch=sse4_1 -xchip=core2 -xO3 -DGC_THREADS -m32 -I/usr/local/GNU/include -L/usr/local/GNU/lib -G -z defs -h libgc.so.1 -o .libs/libgc.so.1.0.3  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/mach_dep.o   -L/usr/local/GNU/lib -ldl -lc  -xarch=sse4_1 -m32 
Undefined                       first referenced
  symbol                             in file
GC_start_world                      .libs/alloc.o
..
ld: fatal: symbol referencing errors. No output written to .libs/libgc.so.1.0.3
make[1]: *** [libgc.la] Error 2
make[1]: Target `all-am' not remade because of errors.
make[1]: Leaving directory `/tmp/ivmai-bdwgc-aee0d2b'
make: *** [all-recursive] Error 1
make: Target `all' not remade because of errors.
make[1]: Entering directory `/tmp/ivmai-bdwgc-aee0d2b'
Looks like PTHREADS AM conditional is undefined (checked in Makefile.am) thus pthread_support.c is not compiled/linked.
Please, if possible, investigate the problem with PTHREADS AM.
(2) master
You are checking "master" branch of libatomic_ops (v7.3alpha1), right?
What about "release" branch of it (is it working or the same problem, or has not been tested)?
It is confusing.
make & make check passed with
(gcc-3.4.3, gcc-4.6.3,  solstudio12.2 cc , solarisstudio12.3 cc) (-m32, -m64)
and (gcc-4.4.7)  (-m64),
but make check fails only with (gcc-4.4.7) (-m32).
libtool: link: gcc -I/tmp/ivmai-master -mtune=core2 -msse3 -mfpmath=sse -O2 -m32 -I/usr/local/GNU/include -Wall -Wextra -D__PIC__=1 -g -O2 -o test_malloc test_malloc.o  -L/usr/local/GNU/lib -lpthread ../src/.libs/libatomic_ops_gpl.a ../src/.libs/libatomic_ops.a
make[3]: Leaving directory `/tmp/ivmai-master/tests'
make  check-TESTS
make[3]: Entering directory `/tmp/ivmai-master/tests'
/bin/bash: line 5: 16359 Segmentation Fault      ${dir}$tst
FAIL: test_atomic
Looks like a compiler bug. We could probably make a workaround
Could you please run it under gdb and tell me exact source line of Seg Fault?
Missing: AO_nop_acquire
Missing: AO_store_acquire
Missing: AO_short_store_acquire
Missing: AO_char_store_acquire
Missing: AO_int_store_acquire
Missing: AO_nop_release
Missing: AO_load_release
Missing: AO_short_load_release
Missing: AO_char_load_release
Missing: AO_int_load_release
Missing: AO_store_read
Missing: AO_short_store_read
Missing: AO_char_store_read
Missing: AO_int_store_read
Missing: AO_load_write
Missing: AO_short_load_write
Missing: AO_char_load_write
Missing: AO_int_load_write
Missing: AO_nop_release_write
Missing: AO_load_release_write
Missing: AO_short_load_release_write
Missing: AO_char_load_release_write
Missing: AO_int_load_release_write
Missing: AO_nop_acquire_read
Missing: AO_store_acquire_read
Missing: AO_short_store_acquire_read
Missing: AO_char_store_acquire_read
Missing: AO_int_store_acquire_read
Testing add1/sub1
Succeeded
I do not know what "Missing: AO..." mean, but they are found also in cases make check pass.
Missing AO_XXX is normal.
Regards.
Post by Ivan Maidanski
Hi Kiyoshi,
Post by Kiyoshi KANAZAWA
Post by Kiyoshi KANAZAWA
Everything is OK now.
I tested all the combination of
(gcc-4.6.3, gcc-4.4.7, gcc-4.6.3), (-m32, -m64), (gc-7.1, gc-7.2alpha6).
wong: (gcc-4.6.3, gcc-4.4.7, gcc-4.6.3)
correct  (gcc-3.4.3, gcc-4.4.7, gcc-4.6.3)
wget https://github.com/ivmai/bdwgc/zipball/release
unzip release
cd ivmai-bdwgc-*/
wget https://github.com/ivmai/libatomic_ops/zipball/release
unzip release
mv ivmai-libatomic_ops-* libatomic_ops
./configure
make check
The same for "master" branch (corresponding to 7.3alpha2 candidate): just replace "release" with "master" and call ./autogen.sh before ./configure
Regards.
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Kiyoshi KANAZAWA
2012-04-01 05:28:57 UTC
Permalink
Hi, Ivan,

I may encountered some problem again with "release" branch.

"Segmentation Fault" happened in building guile-2.0.5 with -m64 option.

It seems to happen in os_dep.c of GC function:
What I checked is:
% pwd
/tmp/guile-2.0.5/libguile/.libs
% ldd guile
libguile-2.0.so.22 => /tmp/guile-2.0.5/libguile/.libs/libguile-2.0.so.22
libgc.so.1 => /usr/local/GNU/amd64/lib/libgc.so.1
libpthread.so.1 => /usr/lib/amd64/libpthread.so.1
libdl.so.1 => /usr/lib/amd64/libdl.so.1
libffi.so.5 => /usr/local/GNU/amd64/lib/libffi.so.5
libintl.so.8 => /usr/local/GNU/amd64/lib/libintl.so.8
libc.so.1 => /usr/lib/amd64/libc.so.1
libunistring.so.0 => /usr/local/GNU/amd64/lib/libunistring.so.0
libiconv.so.2 => /usr/local/GNU/amd64/lib/libiconv.so.2
libgmp.so.10 => /usr/local/GNU/amd64/lib/libgmp.so.10
libltdl.so.7 => /usr/local/GNU/amd64/lib/libltdl.so.7
librt.so.1 => /usr/lib/amd64/librt.so.1
libsocket.so.1 => /usr/lib/amd64/libsocket.so.1
libnsl.so.1 => /usr/lib/amd64/libnsl.so.1
libm.so.2 => /usr/lib/amd64/libm.so.2
libgcc_s.so.1 => /usr/local/gcc/lib/amd64/libgcc_s.so.1
libaio.so.1 => /usr/lib/amd64/libaio.so.1
libmd.so.1 => /usr/lib/amd64/libmd.so.1
libmp.so.2 => /usr/lib/amd64/libmp.so.2
libscf.so.1 => /usr/lib/amd64/libscf.so.1
libdoor.so.1 => /usr/lib/amd64/libdoor.so.1
libuutil.so.1 => /usr/lib/amd64/libuutil.so.1
libgen.so.1 => /usr/lib/amd64/libgen.so.1

libpthread.so.1 is linked to /usr/lib/amd64/libpthread.so.1 in the 3rd line.
Is this strange ?

% dbx guile
(dbx) run
Running: guile
(process id 742)
***@1 (***@1) signal SEGV (no mapping at the fault address) in GC_SysVGetDataStart at line 1859 in file "os_dep.c"
1859 *result = *result;
(dbx) print result
result = 0x402270 "<bad address 0x0000000000402270>"

"os_dep.o" is compiled and linked to .libs/libgc.so.1.0.3: in make log:
libtool: compile: gcc -O2 -m64 -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2 -fno-strict-aliasing -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c -fPIC -DPIC -o .libs/os_dep.o
libtool: compile: gcc -O2 -m64 -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2 -fno-strict-aliasing -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c -o os_dep.o >/dev/null 2>&1
libtool: link: gcc -O2 -m64 -shared -fPIC -DPIC -Wl,-z -Wl,text -Wl,-h -Wl,libgc.so.1 -o .libs/libgc.so.1.0.3 .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gc_dlopen.o .libs/gcj_mlc.o .libs/headers.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/specific.o .libs/stubborn.o .libs/typd_mlc.o .libs/backgraph.o .libs/thread_local_alloc.o .libs/pthread_start.o .libs/pthread_support.o .libs/pthread_stop_world.o .libs/atomic_ops.o .libs/mach_dep.o -R/usr/lib/lwp/amd64 -L/usr/local/GNU/amd64/lib -L/usr/lib/lwp/amd64 -lpthread -lrt -ldl -lc -mtune=athlon64 -msse3 -mno-3dnow -msse -mfpmath=sse -O2 -m64 -O2

Do you have any suggestion ?

Regards,

--- Kiyoshi <***@yahoo.co.jp>
Ivan Maidanski
2012-04-01 06:15:42 UTC
Permalink
Hi Kiyoshi,
Hi, Ivan,
I may encountered some problem again with "release" branch.
Again, do you mean here you haven't checked bdwgc "master" branch or you don't have this problem with it?
"Segmentation Fault" happened in building guile-2.0.5 with -m64 option.
% pwd
/tmp/guile-2.0.5/libguile/.libs
% ldd guile
libguile-2.0.so.22 => /tmp/guile-2.0.5/libguile/.libs/libguile-2.0.so.22
libgc.so.1 => /usr/local/GNU/amd64/lib/libgc.so.1
libpthread.so.1 => /usr/lib/amd64/libpthread.so.1
libdl.so.1 => /usr/lib/amd64/libdl.so.1
libffi.so.5 => /usr/local/GNU/amd64/lib/libffi.so.5
libintl.so.8 => /usr/local/GNU/amd64/lib/libintl.so.8
libc.so.1 => /usr/lib/amd64/libc.so.1
libunistring.so.0 => /usr/local/GNU/amd64/lib/libunistring.so.0
libiconv.so.2 => /usr/local/GNU/amd64/lib/libiconv.so.2
libgmp.so.10 => /usr/local/GNU/amd64/lib/libgmp.so.10
libltdl.so.7 => /usr/local/GNU/amd64/lib/libltdl.so.7
librt.so.1 => /usr/lib/amd64/librt.so.1
libsocket.so.1 => /usr/lib/amd64/libsocket.so.1
libnsl.so.1 => /usr/lib/amd64/libnsl.so.1
libm.so.2 => /usr/lib/amd64/libm.so.2
libgcc_s.so.1 => /usr/local/gcc/lib/amd64/libgcc_s.so.1
libaio.so.1 => /usr/lib/amd64/libaio.so.1
libmd.so.1 => /usr/lib/amd64/libmd.so.1
libmp.so.2 => /usr/lib/amd64/libmp.so.2
libscf.so.1 => /usr/lib/amd64/libscf.so.1
libdoor.so.1 => /usr/lib/amd64/libdoor.so.1
libuutil.so.1 => /usr/lib/amd64/libuutil.so.1
libgen.so.1 => /usr/lib/amd64/libgen.so.1
libpthread.so.1 is linked to /usr/lib/amd64/libpthread.so.1 in the 3rd line.
Is this strange ?
I don't know. What are the alternatives?
% dbx guile
(dbx) run
Running: guile
(process id 742)
1859 *result = *result;
I think this is the expected behavior. Ignore this signal in debugger.
(dbx) print result
result = 0x402270 "<bad address 0x0000000000402270>"
But the address looks too small for x64 target. Check GC_SysVGetDataStart parameters passed (compare to that in gctest).

Regards.
libtool: compile: gcc -O2 -m64 -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2 -fno-strict-aliasing -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c -fPIC -DPIC -o .libs/os_dep.o
...
Do you have any suggestion ?
Regards,
Kiyoshi KANAZAWA
2012-04-01 06:43:21 UTC
Permalink
I haven't checked bdwgc "master" branch yet.
I'd like to do that after clearing in "release" branch.

GC_SysVGetDataStart passed is:
in guile:
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff16f940

in gctest
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff31f940

Regards,
Post by Ivan Maidanski
Hi Kiyoshi,
Hi, Ivan,
I may encountered some problem again with "release" branch.
Again, do you mean here you haven't checked bdwgc "master" branch or you don't have this problem with it?
"Segmentation Fault" happened in building guile-2.0.5 with -m64 option.
% pwd
/tmp/guile-2.0.5/libguile/.libs
% ldd guile
         libguile-2.0.so.22 =>    /tmp/guile-2.0.5/libguile/.libs/libguile-2.0.so.22
         libgc.so.1 =>    /usr/local/GNU/amd64/lib/libgc.so.1
         libpthread.so.1 =>       /usr/lib/amd64/libpthread.so.1
         libdl.so.1 =>    /usr/lib/amd64/libdl.so.1
         libffi.so.5 =>   /usr/local/GNU/amd64/lib/libffi.so.5
         libintl.so.8 =>  /usr/local/GNU/amd64/lib/libintl.so.8
         libc.so.1 =>     /usr/lib/amd64/libc.so.1
         libunistring.so.0 =>     /usr/local/GNU/amd64/lib/libunistring.so.0
         libiconv.so.2 =>         /usr/local/GNU/amd64/lib/libiconv.so.2
         libgmp.so.10 =>  /usr/local/GNU/amd64/lib/libgmp.so.10
         libltdl.so.7 =>  /usr/local/GNU/amd64/lib/libltdl.so.7
         librt.so.1 =>    /usr/lib/amd64/librt.so.1
         libsocket.so.1 =>        /usr/lib/amd64/libsocket.so.1
         libnsl.so.1 =>   /usr/lib/amd64/libnsl.so.1
         libm.so.2 =>     /usr/lib/amd64/libm.so.2
         libgcc_s.so.1 =>         /usr/local/gcc/lib/amd64/libgcc_s.so.1
         libaio.so.1 =>   /usr/lib/amd64/libaio.so.1
         libmd.so.1 =>    /usr/lib/amd64/libmd.so.1
         libmp.so.2 =>    /usr/lib/amd64/libmp.so.2
         libscf.so.1 =>   /usr/lib/amd64/libscf.so.1
         libdoor.so.1 =>  /usr/lib/amd64/libdoor.so.1
         libuutil.so.1 =>         /usr/lib/amd64/libuutil.so.1
         libgen.so.1 =>   /usr/lib/amd64/libgen.so.1
libpthread.so.1 is linked to /usr/lib/amd64/libpthread.so.1 in the 3rd line.
Is this strange ?
I don't know. What are the alternatives?
% dbx guile
(dbx) run                                                                   
Running: guile
(process id 742)
  1859           *result = *result;
I think this is the expected behavior. Ignore this signal in debugger.
(dbx) print result
result = 0x402270 "<bad address 0x0000000000402270>"
But the address looks too small for x64 target. Check GC_SysVGetDataStart parameters passed (compare to that in gctest).
Regards.
libtool: compile:  gcc -O2 -m64 -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2 -fno-strict-aliasing -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c  -fPIC -DPIC -o .libs/os_dep.o
...
Do you have any suggestion ?
Regards,
Ivan Maidanski
2012-04-01 06:52:18 UTC
Permalink
Hi,
Post by Kiyoshi KANAZAWA
I haven't checked bdwgc "master" branch yet.
I'd like to do that after clearing in "release" branch.
... Check GC_SysVGetDataStart parameters passed (compare to that in gctest).
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff16f940
in gctest
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff31f940
Code address is not needed to be compared I guess. Check params.

Regards.
Post by Kiyoshi KANAZAWA
Regards,
Hi Kiyoshi,
Hi, Ivan,
I may encountered some problem again with "release" branch.
Again, do you mean here you haven't checked bdwgc "master" branch or you don't have this problem with it?
"Segmentation Fault" happened in building guile-2.0.5 with -m64 option.
% pwd
/tmp/guile-2.0.5/libguile/.libs
% ldd guile
         libguile-2.0.so.22 =>    /tmp/guile-2.0.5/libguile/.libs/libguile-2.0.so.22
         libgc.so.1 =>    /usr/local/GNU/amd64/lib/libgc.so.1
         libpthread.so.1 =>       /usr/lib/amd64/libpthread.so.1
         libdl.so.1 =>    /usr/lib/amd64/libdl.so.1
         libffi.so.5 =>   /usr/local/GNU/amd64/lib/libffi.so.5
         libintl.so.8 =>  /usr/local/GNU/amd64/lib/libintl.so.8
         libc.so.1 =>     /usr/lib/amd64/libc.so.1
         libunistring.so.0 =>     /usr/local/GNU/amd64/lib/libunistring.so.0
         libiconv.so.2 =>         /usr/local/GNU/amd64/lib/libiconv.so.2
         libgmp.so.10 =>  /usr/local/GNU/amd64/lib/libgmp.so.10
         libltdl.so.7 =>  /usr/local/GNU/amd64/lib/libltdl.so.7
         librt.so.1 =>    /usr/lib/amd64/librt.so.1
         libsocket.so.1 =>        /usr/lib/amd64/libsocket.so.1
         libnsl.so.1 =>   /usr/lib/amd64/libnsl.so.1
         libm.so.2 =>     /usr/lib/amd64/libm.so.2
         libgcc_s.so.1 =>         /usr/local/gcc/lib/amd64/libgcc_s.so.1
         libaio.so.1 =>   /usr/lib/amd64/libaio.so.1
         libmd.so.1 =>    /usr/lib/amd64/libmd.so.1
         libmp.so.2 =>    /usr/lib/amd64/libmp.so.2
         libscf.so.1 =>   /usr/lib/amd64/libscf.so.1
         libdoor.so.1 =>  /usr/lib/amd64/libdoor.so.1
         libuutil.so.1 =>         /usr/lib/amd64/libuutil.so.1
         libgen.so.1 =>   /usr/lib/amd64/libgen.so.1
libpthread.so.1 is linked to /usr/lib/amd64/libpthread.so.1 in the 3rd line.
Is this strange ?
I don't know. What are the alternatives?
% dbx guile
(dbx) run                                                                   
Running: guile
(process id 742)
  1859           *result = *result;
I think this is the expected behavior. Ignore this signal in debugger.
(dbx) print result
result = 0x402270 "<bad address 0x0000000000402270>"
But the address looks too small for x64 target. Check GC_SysVGetDataStart parameters passed (compare to that in gctest).
Regards.
libtool: compile:  gcc -O2 -m64 -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2 -fno-strict-aliasing -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c  -fPIC -DPIC -o .libs/os_dep.o
...
Do you have any suggestion ?
Regards,
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Kiyoshi KANAZAWA
2012-04-01 07:11:10 UTC
Permalink
Hi, Ivan,

Parameters of GC_SysVGetDataStart are:
guile:
(dbx) print max_page_size
max_page_size = 18446741324915316480U
(dbx) print etext_addr
etext_addr = 0xfffffd7fffdfe450 ""

gctest:
(dbx) print max_page_size
max_page_size = 4448192U
(dbx) print etext_addr
etext_addr = 0xfffffd7fffdfe530 ""

max_page_size in guile too large ?

Regards,
Post by Ivan Maidanski
Hi,
Post by Kiyoshi KANAZAWA
I haven't checked bdwgc "master" branch yet.
I'd like to do that after clearing in "release" branch.
... Check GC_SysVGetDataStart parameters passed (compare to that in gctest).
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff16f940
in gctest
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff31f940
Code address is not needed to be compared I guess. Check params.
Regards.
Post by Kiyoshi KANAZAWA
Regards,
Hi Kiyoshi,
Hi, Ivan,
I may encountered some problem again with "release" branch.
Again, do you mean here you haven't checked bdwgc "master" branch or you don't have this problem with it?
"Segmentation Fault" happened in building guile-2.0.5 with -m64 option.
% pwd
/tmp/guile-2.0.5/libguile/.libs
% ldd guile
         libguile-2.0.so.22 =>    /tmp/guile-2.0.5/libguile/.libs/libguile-2.0.so.22
         libgc.so.1 =>    /usr/local/GNU/amd64/lib/libgc.so.1
         libpthread.so.1 =>       /usr/lib/amd64/libpthread.so.1
         libdl.so.1 =>    /usr/lib/amd64/libdl.so.1
         libffi.so.5 =>   /usr/local/GNU/amd64/lib/libffi.so.5
         libintl.so.8 =>  /usr/local/GNU/amd64/lib/libintl.so.8
         libc.so.1 =>     /usr/lib/amd64/libc.so.1
         libunistring.so.0 =>     /usr/local/GNU/amd64/lib/libunistring.so.0
         libiconv.so.2 =>         /usr/local/GNU/amd64/lib/libiconv.so.2
         libgmp.so.10 =>  /usr/local/GNU/amd64/lib/libgmp.so.10
         libltdl.so.7 =>  /usr/local/GNU/amd64/lib/libltdl.so.7
         librt.so.1 =>    /usr/lib/amd64/librt.so.1
         libsocket.so.1 =>        /usr/lib/amd64/libsocket.so.1
         libnsl.so.1 =>   /usr/lib/amd64/libnsl.so.1
         libm.so.2 =>     /usr/lib/amd64/libm.so.2
         libgcc_s.so.1 =>         /usr/local/gcc/lib/amd64/libgcc_s.so.1
         libaio.so.1 =>   /usr/lib/amd64/libaio.so.1
         libmd.so.1 =>    /usr/lib/amd64/libmd.so.1
         libmp.so.2 =>    /usr/lib/amd64/libmp.so.2
         libscf.so.1 =>   /usr/lib/amd64/libscf.so.1
         libdoor.so.1 =>  /usr/lib/amd64/libdoor.so.1
         libuutil.so.1 =>         /usr/lib/amd64/libuutil.so.1
         libgen.so.1 =>   /usr/lib/amd64/libgen.so.1
libpthread.so.1 is linked to /usr/lib/amd64/libpthread.so.1 in the 3rd line.
Is this strange ?
I don't know. What are the alternatives?
% dbx guile
(dbx) run                                                                   
Running: guile
(process id 742)
  1859           *result = *result;
I think this is the expected behavior. Ignore this signal in debugger.
(dbx) print result
result = 0x402270 "<bad address 0x0000000000402270>"
But the address looks too small for x64 target. Check GC_SysVGetDataStart parameters passed (compare to that in gctest).
Regards.
libtool: compile:  gcc -O2 -m64 -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2 -fno-strict-aliasing -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c  -fPIC -DPIC -o .libs/os_dep.o
...
Do you have any suggestion ?
Regards,
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Ivan Maidanski
2012-04-01 12:36:29 UTC
Permalink
Hi Kyioshi,
Hi, Ivan,
(dbx) print max_page_size
max_page_size = 18446741324915316480U
(dbx) print etext_addr
etext_addr = 0xfffffd7fffdfe450 ""
(dbx) print max_page_size
max_page_size = 4448192U
(dbx) print etext_addr
etext_addr = 0xfffffd7fffdfe530 ""
max_page_size in guile too large ?
Right. In both cases.

In gconfig.h, I can see only values in range 0x1000 ... 0x100000 for this parameter.

Regards.
Regards,
Post by Ivan Maidanski
Hi,
Post by Kiyoshi KANAZAWA
I haven't checked bdwgc "master" branch yet.
I'd like to do that after clearing in "release" branch.
... Check GC_SysVGetDataStart parameters passed (compare to that in gctest).
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff16f940
in gctest
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff31f940
Code address is not needed to be compared I guess. Check params.
Regards.
Post by Kiyoshi KANAZAWA
Regards,
Hi Kiyoshi,
Hi, Ivan,
I may encountered some problem again with "release" branch.
Again, do you mean here you haven't checked bdwgc "master" branch or you don't have this problem with it?
"Segmentation Fault" happened in building guile-2.0.5 with -m64 option.
% pwd
/tmp/guile-2.0.5/libguile/.libs
% ldd guile
         libguile-2.0.so.22 =>    /tmp/guile-2.0.5/libguile/.libs/libguile-2.0.so.22
         libgc.so.1 =>    /usr/local/GNU/amd64/lib/libgc.so.1
         libpthread.so.1 =>       /usr/lib/amd64/libpthread.so.1
         libdl.so.1 =>    /usr/lib/amd64/libdl.so.1
         libffi.so.5 =>   /usr/local/GNU/amd64/lib/libffi.so.5
         libintl.so.8 =>  /usr/local/GNU/amd64/lib/libintl.so.8
         libc.so.1 =>     /usr/lib/amd64/libc.so.1
         libunistring.so.0 =>     /usr/local/GNU/amd64/lib/libunistring.so.0
         libiconv.so.2 =>         /usr/local/GNU/amd64/lib/libiconv.so.2
         libgmp.so.10 =>  /usr/local/GNU/amd64/lib/libgmp.so.10
         libltdl.so.7 =>  /usr/local/GNU/amd64/lib/libltdl.so.7
         librt.so.1 =>    /usr/lib/amd64/librt.so.1
         libsocket.so.1 =>        /usr/lib/amd64/libsocket.so.1
         libnsl.so.1 =>   /usr/lib/amd64/libnsl.so.1
         libm.so.2 =>     /usr/lib/amd64/libm.so.2
         libgcc_s.so.1 =>         /usr/local/gcc/lib/amd64/libgcc_s.so.1
         libaio.so.1 =>   /usr/lib/amd64/libaio.so.1
         libmd.so.1 =>    /usr/lib/amd64/libmd.so.1
         libmp.so.2 =>    /usr/lib/amd64/libmp.so.2
         libscf.so.1 =>   /usr/lib/amd64/libscf.so.1
         libdoor.so.1 =>  /usr/lib/amd64/libdoor.so.1
         libuutil.so.1 =>         /usr/lib/amd64/libuutil.so.1
         libgen.so.1 =>   /usr/lib/amd64/libgen.so.1
libpthread.so.1 is linked to /usr/lib/amd64/libpthread.so.1 in the 3rd line.
Is this strange ?
I don't know. What are the alternatives?
% dbx guile
(dbx) run                                                                   
Running: guile
(process id 742)
  1859           *result = *result;
I think this is the expected behavior. Ignore this signal in debugger.
(dbx) print result
result = 0x402270 "<bad address 0x0000000000402270>"
But the address looks too small for x64 target. Check GC_SysVGetDataStart parameters passed (compare to that in gctest).
Regards.
libtool: compile:  gcc -O2 -m64 -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2 -fno-strict-aliasing -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c  -fPIC -DPIC -o .libs/os_dep.o
...
Do you have any suggestion ?
Regards,
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Kiyoshi KANAZAWA
2012-04-01 12:52:28 UTC
Permalink
Thank you Ivan,

Ignoring the signal in this function, as you told me,
another function call with bad address was found in guile.
It does not seem to be an error in GC.

Very sorry to trouble you.
Post by Ivan Maidanski
Hi Kyioshi,
Hi, Ivan,
(dbx) print max_page_size
max_page_size = 18446741324915316480U
(dbx) print etext_addr   
etext_addr = 0xfffffd7fffdfe450 ""
(dbx) print max_page_size
max_page_size = 4448192U
(dbx) print etext_addr   
etext_addr = 0xfffffd7fffdfe530 ""
max_page_size in guile too large ?
Right. In both cases.
In gconfig.h, I can see only values in range 0x1000 ... 0x100000 for this parameter.
Regards.
Regards,
Post by Ivan Maidanski
Hi,
Post by Kiyoshi KANAZAWA
I haven't checked bdwgc "master" branch yet.
I'd like to do that after clearing in "release" branch.
... Check GC_SysVGetDataStart parameters passed (compare to that in gctest).
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff16f940
in gctest
(dbx) print GC_SysVGetDataStart
GC_SysVGetDataStart = &GC_SysVGetDataStart(register size_t max_page_size, register ptr_t etext_addr) at 0xfffffd7fff31f940
Code address is not needed to be compared I guess. Check params.
Regards.
Post by Kiyoshi KANAZAWA
Regards,
Hi Kiyoshi,
Hi, Ivan,
I may encountered some problem again with "release" branch.
Again, do you mean here you haven't checked bdwgc "master" branch or you don't have this problem with it?
"Segmentation Fault" happened in building guile-2.0.5 with -m64 option.
% pwd
/tmp/guile-2.0.5/libguile/.libs
% ldd guile
         libguile-2.0.so.22 =>    /tmp/guile-2.0.5/libguile/.libs/libguile-2.0.so.22
         libgc.so.1 =>    /usr/local/GNU/amd64/lib/libgc.so.1
         libpthread.so.1 =>       /usr/lib/amd64/libpthread.so.1
         libdl.so.1 =>    /usr/lib/amd64/libdl.so.1
         libffi.so.5 =>   /usr/local/GNU/amd64/lib/libffi.so.5
         libintl.so.8 =>  /usr/local/GNU/amd64/lib/libintl.so.8
         libc.so.1 =>     /usr/lib/amd64/libc.so.1
         libunistring.so.0 =>     /usr/local/GNU/amd64/lib/libunistring.so.0
         libiconv.so.2 =>         /usr/local/GNU/amd64/lib/libiconv.so.2
         libgmp.so.10 =>  /usr/local/GNU/amd64/lib/libgmp.so.10
         libltdl.so.7 =>  /usr/local/GNU/amd64/lib/libltdl.so.7
         librt.so.1 =>    /usr/lib/amd64/librt.so.1
         libsocket.so.1 =>        /usr/lib/amd64/libsocket.so.1
         libnsl.so.1 =>   /usr/lib/amd64/libnsl.so.1
         libm.so.2 =>     /usr/lib/amd64/libm.so.2
         libgcc_s.so.1 =>         /usr/local/gcc/lib/amd64/libgcc_s.so.1
         libaio.so.1 =>   /usr/lib/amd64/libaio.so.1
         libmd.so.1 =>    /usr/lib/amd64/libmd.so.1
         libmp.so.2 =>    /usr/lib/amd64/libmp.so.2
         libscf.so.1 =>   /usr/lib/amd64/libscf.so.1
         libdoor.so.1 =>  /usr/lib/amd64/libdoor.so.1
         libuutil.so.1 =>         /usr/lib/amd64/libuutil.so.1
         libgen.so.1 =>   /usr/lib/amd64/libgen.so.1
libpthread.so.1 is linked to /usr/lib/amd64/libpthread.so.1 in the 3rd line.
Is this strange ?
I don't know. What are the alternatives?
% dbx guile
(dbx) run                                                                   
Running: guile
(process id 742)
  1859           *result = *result;
I think this is the expected behavior. Ignore this signal in debugger.
(dbx) print result
result = 0x402270 "<bad address 0x0000000000402270>"
But the address looks too small for x64 target. Check GC_SysVGetDataStart parameters passed (compare to that in gctest).
Regards.
libtool: compile:  gcc -O2 -m64 -DHAVE_CONFIG_H -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src -fexceptions -g -O2 -fno-strict-aliasing -MT os_dep.lo -MD -MP -MF .deps/os_dep.Tpo -c os_dep.c  -fPIC -DPIC -o .libs/os_dep.o
...
Do you have any suggestion ?
Regards,
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
_______________________________________________
Gc mailing list
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
Loading...