boost::any_range<gsl::string_span<>> crash in Release mode

Question

I'm observing a rather weird behaviour of the following piece of code:

#include <boost/range/adaptor/transformed.hpp>
#include <boost/range/any_range.hpp>

#include <vector>
#include <string>
#include <iostream>

#include "gsl.h"

template <typename T>
using ImmutableValueRange = boost::any_range<T, boost::bidirectional_traversal_tag, /*const*/ T>;

template <typename T, typename C>
ImmutableValueRange<T> make_transforming_immutable_range(const C& container)
{
    return container | boost::adaptors::transformed([](const typename C::value_type& v) -> T 
    {
        //std::cout << "trans : " << T{ v }.data() << "\n";
        return T{ v }; 
    });
}

void f(ImmutableValueRange<gsl::cstring_span<>> r)
{
    for (const auto& c : r) {
        std::cout << c.data() << "\n";
    }
}

int main()
{
    std::vector<std::string> v({ "x", "y", "z" });

    f(make_transforming_immutable_range<gsl::cstring_span<>>(v));
}

The idea here is to isolate the actual representation of a sequence of strings that is received as a parameter by the function f behind an any_range and gsl::string_span (note, the commit changing string_view to string_span has been made a couple of hours ago to GSL).

My original code did not have a const T as Reference template parameter to any_range (it was a simple T) and it crashed during execution. However, that happened only in Release mode an worked fine in Debug or RelWithDebInfo (generated by CMake). I used VS2013/2015 x64. Furthermore, trying to debug the full Release version, adding debug output to the conversion lambda eliminated the crash (my guess is it prevented some inlining). My final working solution is to specify const T as Reference.

However, I'm still wondering why did the crash happen in the first place? Is it the VS compiler bug? Bug in the current implementation of string_span? Or am I simply misusing the boost::any_range?

Edit

Just built the version with clang 3.7.0 and the behaviour is similar (works fine in debug and doesn't crash, but outputs garbage without const T with -O2). So it doesn't seem like a compiler problem.

Answer 1

After a quick look, I suspect the problem lies in your lambda. If I understood correctly, you end up taking a std::string by const reference with the following parameter declaration:

const typename C::value_type& v

However, you are then using v to construct a cstring_span. Here's the rub: cstring_span only has a constructor that goes from a non-const reference to a container type (like std::string). Conceptually, the constructor looks like this:

template <class Cont> cstring_span(Cont& c)

So I am guessing that when you return from your lambda, a temporary is being created from v, and then passed to the cstring_span constructor in order to provide a non-const reference argument. Of course, once that temporary gets cleaned up, your cstring_span is left dangling.

Answer 2

As it turns out, the any_range's dereference method will return a reference to T unless the Reference type is specified as const T, thus creating a dangling reference to a temporary. This happens due to use of any_incrementable_iterator_interface::mutable_reference_type_generator defined in any_iterator_interface.hpp.

Therefore, the correct solution to the problem is indeed to specify const T as the Reference type in case the iterator dereferencing returns a temporary.

Answer 3

This is a bug in boost::range and a fix was only merged in Feb of 2020, but didn't make it into 1.73. The fix is available as of 1.74

https://github.com/boostorg/range/pull/94