Re: [lock-free] SMR pointer storage checked with Relacy race detector.

[Dmitry Vyukov]

Hi Artur,

I don't have time to investigate this issue right now. But looking at
the failure, disabling source fortification may help. Try to build the
program with -D_FORTIFY_SOURCE=0 compiler flag.



On Fri, May 22, 2015 at 11:18 AM, Artur Brugeman
<brugema...@gmail.com> wrote:
> Hello.
>
> I'm trying to implement a lock-free pointer storage with safe memory
> reclamation. That is, whenever a writer tries to replace an old pointer with
> new one, it waits until all readers are done with old pointer, so that old
> pointed memory can be released safely.
>
> To verify the code I'm checking it with Relacy race detector. Here it is:
> https://gist.github.com/brugeman/30070d4c309a17f21597
> I compile it this way:
> g++-4.8 -g -std=c++11 -Wall -Irelacy_2_4 -o smrp_test smrp_test.cpp
>
> I face some problems:
> 1. Even though test passes and relacy does not give any warnings, the same
> test w/o relacy-related stuff will occasionally fail on this assertion:
> https://gist.github.com/brugeman/30070d4c309a17f21597#file-smrp_test-cpp-L223
>
> Could anyone please comment on the algorithm in general, and on
> memory-orderings in particular? Whenever I change all memory orders to
> seq_cst, I see 20x performance degradation, but see no errors (although they
> might just have become rarer).
>
> 2. If I compile with -O1 or higher, program crashes:
> *** longjmp causes uninitialized stack frame ***: smrp_test terminated
>
> Stack trace:
> #0 0x00007ffff74be0d5 in __GI_raise (sig=<optimized out>) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #1 0x00007ffff74c183b in __GI_abort () at abort.c:91
> #2 0x00007ffff74fb32e in __libc_message (do_abort=2, fmt=0x7ffff7603412
> "*** %s ***: %s terminated\n")
> at ../sysdeps/unix/sysv/linux/libc_fatal.c:201
> #3 0x00007ffff7591e57 in __GI___fortify_fail (msg=0x7ffff76033d1 "longjmp
> causes uninitialized stack frame") at fortify_fail.c:32
> #4 0x00007ffff7591dcd in ____longjmp_chk () at
> ../sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S:90
> #5 0x00007ffff7591d33 in __longjmp_chk (env=0x7fffffffd928, val=<optimized
> out>) at ../setjmp/longjmp.c:40
> #6 0x0000000000405daf in switch_to_fiber(fiber_t&, fiber_t&) () at
> relacy_2_4/relacy/platform.hpp:223
> #7 0x000000000040f02a in rl::test_result_e
> rl::run_test<smrp_test::race_test, rl::random_scheduler<2>
>>(rl::test_params&, std::ostream&, bool) () at
> relacy_2_4/relacy/context.hpp:703
> #8 0x0000000000410e65 in bool
> rl::simulate<smrp_test::race_test>(rl::test_params&) () at
> relacy_2_4/relacy/context.hpp:960
> #9 0x00000000004112df in bool rl::simulate<smrp_test::race_test>() () at
> relacy_2_4/relacy/context.hpp:1014
> #10 0x0000000000402658 in main () at smrp_test.cpp:247
>
> Dmitry, could you please comment - is this expected? Should I only run
> relacy with optimizations turned off? Not that I really need optimization
> here, just saying in case there's some bug...
>
> Thanks!
> --
> Artur
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Scalable Synchronization Algorithms" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lock-free+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/lock-free/ed86f08f-2ca6-4cd3-a6b7-03599356d555%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Dmitry Vyukov

All about lockfree/waitfree algorithms, multicore, scalability,
parallel computing and related topics:
http://www.1024cores.net