[erlang-bugs] otp --with-libatomic_ops compile hangs

[Rickard Green]

Rickard Green wrote:
>> Feng Yu wrote:
>>> Build Options:  --with-libatomic_ops=/usr
>>>
>>> Arch:
>>>     Linux yufeng-laptop 2.6.32-25-generic #43-Ubuntu SMP Wed Sep 1 
>>> 09:46:13
>>> UTC 2010 x86_64 GNU/Linux
>>>
>>> Libatomic_ops:
>>>     apt-get -y install libatomic-ops-dev
>>>
>>> Symptom: beam.smp hangs/doesn't terminate
>>>
>>> Steps to reproduce:
>>>
>>> There are two known ways to reproduce the issue and the simplest is:
>>>
>>> $ git clone git://github.com/erlang/otp.git
>>> $ cd otp
>>> $ ./otp_build autoconf
>>> $ ./configure --with-libatomic_ops=/usr
>>> $ make
>>> [...]
>>> make[4]:=D5=FD=D4=DA=C0=EB=BF=AA=C4=BF=C2=BC 
>>> `/usr/src/otp/lib/hipe/main'
>>> erlc -W  +debug_info +inline -o../ebin hipe_rtl.erl
>>>
>>> make hang here.
>>
>> Configuring with libatomic_ops seems to be a new option since
>> post-R14A.  Since you're on x86_64 Linux you shouldn't need it.
>>
>> Does it work without that option?
> 
> I was able to reproduce the hang using libatomic_ops-1.2 and 
> libatomic_ops-7.2alpha4 on an Ubuntu 9.10, x86_64, gcc 4.4.1. However, 
> using the atomic implementation part of OTP every things works fine.
> 
> On SLES 10.1, x86_64, gcc 4.1.2, libatomic_ops-7.2alpha4 worked fine.
> 
> We have added support for use of libatomic_ops since it makes it 
> possible to utilize optimized native atomic operations on more platforms 
> than before. On x86_64 there is however no need to use libatomic_ops. If 
> configure doesn't complain, there is no need for libatomic_ops.
> 
> Cut from release the note:
>    The ethread library contains native atomic implementations for, x86
>    (32 and 64 bit), powerpc (32 bit), sparc V9 (32 and 64 bit), and
>    tilera (32 bit). On other hardware gcc's builtin support for atomic
>    memory access will be used if such exists. If no such support is
>    found, configure will warn about no atomic implementation available.
> 
>    The ethread library can now also use the libatomic_ops library for
>    atomic memory accesses. This makes it possible for the Erlang runtime
>    system to utilize optimized native atomic operations on more
>    platforms than before. If configure warns about no atomic
>    implementation available, try using the libatomic_ops library. Use
>    the --with-libatomic_ops=PATH configure command line argument when
>    specifying where the libatomic_ops installation is located. The
>    libatomic_ops library can be downloaded from:
>    http://www.hpl.hp.com/research/linux/atomic_ops/
> 
> It looks like a bug outside of OTP, and we currently don't have the time 
> to look closer into this, but we will do that when time allows us some 
> time in the future.
> 
> Regards,
> Rickard Green

AO_compare_and_swap_full() for x86_64 in libatomic_ops has been reported 
as buggy: 
http://comments.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3732

I patched AO_compare_and_swap_full() in libatomic_ops-7.2alpha4 with the 
corrected version of fix number 2 by Patrick Marlier (see Patrick 
Marlier's second mail at the page mentioned above).

After applying the fix, the previously hanging build succeeded. However, 
  as mentioned earlier, on x86_64 libatomic_ops isn't needed.

Regards,
Rickard Green
-- 
Rickard Green, Erlang/OTP, Ericsson AB.