Opened 9 years ago

Last modified 8 years ago

#9877 new Bugs

freelist test crashes on Linux/GCC/release/x86

Reported by: gjasny@… Owned by: timblechmann
Milestone: To Be Determined Component: lockfree
Version: Boost Development Trunk Severity: Problem
Keywords: Cc:

Description

Hello,

on a Redhat 6.5 system with GCC 4.4.7 I compiled the latest trunk with these parameters: toolset=gcc architecture=x86 address-model=32 variant=release

I get the following error in the testsuite:

unknown location(0): fatal error in "fixed_size_freelist_test": memory access violation at address: 0x1c93bbed: no mapping at fault address
freelist_test.cpp(113): last checkpoint
(gdb) bt
#0  0x0805d652 in boost::lockfree::queue<dummy*, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::push(dummy* const&) ()
#1  0x0805f1f2 in freelist_tester<boost::lockfree::detail::fixed_size_freelist<dummy, boost::lockfree::detail::runtime_sized_freelist_storage<dummy, std::allocator<dummy> > >, true>::allocate() ()
#2  0x08054367 in boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, freelist_tester<boost::lockfree::detail::fixed_size_freelist<dummy, boost::lockfree::detail::runtime_sized_freelist_storage<dummy, std::allocator<dummy> > >, true> >, boost::_bi::list1<boost::_bi::value<freelist_tester<boost::lockfree::detail::fixed_size_freelist<dummy, boost::lockfree::detail::runtime_sized_freelist_storage<dummy, std::allocator<dummy> > >, true>*> > > >::run()
    ()
#3  0x00125b26 in thread_proxy () from /uhome/gjasny/src/modular-boost/bin.v2/libs/thread/build/gcc-4.4.7/release/address-model-32/architecture-x86/threading-multi/libboost_thread.so.1.56.0
#4  0x00cd1b39 in start_thread () from /lib/libpthread.so.0
#5  0x00c14d6e in clone () from /lib/libc.so.6

I an not able to reproduce the crash in x86 debug mode or any x64 mode.

[gjasny@drsbuild05.drs atomic]$ git describe
fatal: No tags can describe '95c083ddfd990f7c848b785e5a0e9d282da5359b'.
Try --always, or create some tags.


[gjasny@drsbuild05.drs lockfree]$ git describe
fatal: No tags can describe '8ffc9b3f26cd5802655ceb7d4188911f1cf7067d'.
Try --always, or create some tags.

Thanks, Gregor

Change History (6)

comment:1 by gregor.jasny@…, 9 years ago

queue test fails, too:

[gjasny@drsbuild05.drs test]$ ../../../bin.v2/libs/lockfree/test/queue_test.test/gcc-4.4.7/release/address-model-32/architecture-x86/threading-multi/queue_test
Running 7 test cases...
queue_test.cpp(31): fatal error in "simple_queue_test": critical check f.empty() failed

comment:2 by timblechmann, 9 years ago

i cannot reproduce this with gcc-4.8 and the boost develop branch. does it also crash with a different compiler?

comment:3 by gregor.jasny@…, 9 years ago

I cannot reproduce it with clang 3.4 which is also installed on the machine.

To reproduce I will build you an Amazon AWS node tomorrow where you can see the problem.

Thanks, Gregor

comment:4 by timblechmann, 9 years ago

hmm ... could be a compiler bug ... fwiw, gcc-4.4 has been released 5 years ago and hasn't received any updates for the last 2 years. so i tend to close it as wontfix, though i'd happily accept a patch ...

do you have a strong requirement to use gcc-4.4 and no other/newer gcc?

comment:5 by gjasny@…, 8 years ago

Hello Tim,

it looks indeed more like a compiler bug. As far as I can see the queue::initialize function does not work properly. For a brand new queue the _head and _tail values must be identical. With GCC 4.4 this is not the case. I tried to introduce some memory fences but this did not change anything. Adding some logging code makes the bug go away.

Unfortunately we're stuck with GCC 4.4.7 because it is the default compiler in Redhat EL6. But maybe with EL7 around the corner we should strive for an early migration.

Boost 1.55.0 still declares GCC 4.4.7 as a primary compiler. But in the dashboard I see only one Ubuntu system with 4.4.7 and I suspect it builds the 64 bit variant only.

Is there anything I could try to convince GCC to produce the proper code?

Thanks, Gregor

comment:6 by timblechmann, 8 years ago

you could try to configure the data structure as fixed_sized, which should select a different code path and avoids the generation of cmpxchg8b instructions, though it will limit the possible size of the queue.

hth

Note: See TracTickets for help on using tickets.