SMR pointer storage checked with Relacy race detector.

[Artur Brugeman]

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

[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.

> --
>
> ---
> 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

[Artur Brugeman]

Thank you, Dmitry, -D_FORTIFY_SOURCE=0 helped to avoid Relacy crashes with compiler optimizations.

--

Artur

To view this discussion on the web visit https://groups.google.com/d/msgid/lock-free/CAEeQi3s1K0h8yz0Ee1CTCoKyGsiVMw%3DLSEf7F6THsuz_%2B47%2BmQ%40mail.gmail.com.