segfault in snake

[victimsnino]

segfault in snake

[oschonrock]

thanks... built in debug mode... updated details above

[victimsnino]

So, i've found source of issue. Preparing PR

[victimsnino]

Merged. Try if it fixes issues for you too

[oschonrock]

did git pull, re-compilled and pleased to report: "it works for me"

clang UB sanitizer is now also happy

[victimsnino]

Thank you for submitting of issue!
I will check it.

[oschonrock]

https://en.cppreference.com/w/cpp/container/vector/back

"Calling back on an empty container causes undefined behavior."

and by simple debug printing before snake.cpp:28 I got

  std::cerr << body.size() << "\n";

4 
0
[segfault]

I guess the snake body should never be empty, but not understanding the full semantics, I added:

  if (!body.empty()) {
  ...
  }

and now it no longer segfaults

but I can't "play snake"... I just get this.. no key presses seem to do anything:

OK, if I re-add the debug printing, I can see that the size is 4, and then 0 forever. And because of my if(!body.empty) in move_snake the snake never gets "moved".

But I suspect the bug is more to do with: "why is the snake body size suddenly 0".

digging further into it, I enabled some sanitizers and now I get this:

string(APPEND CMAKE_CXX_FLAGS_DEBUG " -fsanitize=address,undefined,leak")

./build/bin/snake 
4
/usr/include/c++/11/bits/stl_iterator.h:1081:45: runtime error: applying non-zero offset 18446744073709551608 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/include/c++/11/bits/stl_iterator.h:1081:45 in 
0

ie just before the snake body goes to size zero, we are applying an offset to a null pointer which is UB.

[victimsnino]

Sounds strange due to no any place to make size 0. It is a reason why there is no checks for it.

[oschonrock]

see above for more info on UB just before it happens... which may also explain why you did not see it? ie my compiler / platform is exhibiting the UB differently to yours.

perhaps if you also turn on sanitizers as shown above, perhaps you can reproduce the UB?

I ma having trouble tracking down where the UB happens right now, but it's definitely happening.

[victimsnino]

In my case it is Windows + MSVC. MSVC has some "evil" extensions which can cause UB on other compilers =C I've reproduced it, under debugging

[oschonrock]

OK..
UB seems to happen immediately upon returning from move_snake():

here my gdb session

top of move_snake4
before rotate body.size() = 4
after rotate body.size() = 4

Breakpoint 1, move_snake (body=..., direction_and_length=std::tuple containing = {...}) at /home/oliver/c/ReactivePlusPlus/src/samples/sfml/snake/snake.cpp:51
51	    std::cerr << "bottom of move_snake body.size() = " << body.size() << "\n";
(gdb) n
bottom of move_snake body.size() = 4
52	  }
(gdb) n
53	  return std::move(body);
(gdb) n
rpp::details::scan_on_next<std::vector<Coordinates, std::allocator<Coordinates> >, std::vector<Coordinates, std::allocator<Coordinates> >&& (*)(std::vector<Coordinates, std::allocator<Coordinates> >&&, std::tuple<Coordinates, unsigned long> const&)>::operator()<std::tuple<Coordinates, unsigned long>, rpp::specific_subscriber<std::vector<Coordinates, std::allocator<Coordinates> >, rpp::details::state_observer<std::vector<Coordinates, std::allocator<Coordinates> >, rpp::details::take_while_impl<std::vector<Coordinates, std::allocator<Coordinates> >, bool (*)(std::vector<Coordinates, std::allocator<Coordinates> > const&)>, rpp::utils::forwarding_on_error, rpp::utils::forwarding_on_completed, rpp::specific_subscriber<std::vector<Coordinates, std::allocator<Coordinates> >, rpp::specific_observer<std::vector<Coordinates, std::allocator<Coordinates> >, rpp::subjects::details::publish_strategy<std::vector<Coordinates, std::allocator<Coordinates> > >::get_subscriber() const::{lambda(std::vector<Coordinates, std::allocator<Coordinates> > const&)#1}, rpp::subjects::details::publish_strategy<std::vector<Coordinates, std::allocator<Coordinates> > >::get_subscriber() const::{lambda(std::__exception_ptr::exception_ptr const&)#1}, rpp::subjects::details::publish_strategy<std::vector<Coordinates, std::allocator<Coordinates> > >::get_subscriber() const::{lambda()#1}> > > > >(std::tuple<Coordinates, unsigned long>&&, rpp::specific_subscriber<std::vector<Coordinates, std::allocator<Coordinates> >, rpp::details::state_observer<std::vector<Coordinates, std::allocator<Coordinates> >, rpp::details::take_while_impl<std::vector<Coordinates, std::allocator<Coordinates> >, bool (*)(std::vector<Coordinates, std::allocator<Coordinates> > const&)>, rpp::utils::forwarding_on_error, rpp::utils::forwarding_on_completed, rpp::specific_subscriber<std::vector<Coordinates, std::allocator<Coordinates> >, rpp::specific_observer<std::vector<Coordinates, std::allocator<Coordinates> >, rpp::subjects::details::publish_strategy<std::vector<Coordinates, std::allocator<Coordinates> > >::get_subscriber() const::{lambda(std::vector<Coordinates, std::allocator<Coordinates> > const&)#1}, rpp::subjects::details::publish_strategy<std::vector<Coordinates, std::allocator<Coordinates> > >::get_subscriber() const::{lambda(std::__exception_ptr::exception_ptr const&)#1}, rpp::subjects::details::publish_strategy<std::vector<Coordinates, std::allocator<Coordinates> > >::get_subscriber() const::{lambda()#1}> > > > const&) const (this=0x60e000002198, 
    value=..., sub=...) at /home/oliver/c/ReactivePlusPlus/src/rpp/rpp/operators/scan.hpp:41
41	        sub.on_next(utils::as_const(m_seed));
(gdb) n
/usr/include/c++/11/bits/stl_iterator.h:1081:45: runtime error: applying non-zero offset 18446744073709551608 to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/include/c++/11/bits/stl_iterator.h:1081:45 in 
42	    }

[victimsnino]

Submitted PR. It looks really strange. MSVC has check over such an situation:

        if (this == _STD addressof(_Right)) {
            return *this;
        }

while gcc/clang not =C

[oschonrock]

I don't follow..

But I noticed you changed the return type of move_snake() to be by-value and not by rvalue ref anymore. I did notice that and thought it was a potential source of a dangling reference.

Is that related?

[victimsnino]

yeah