Storing Lambda in class segfaults

Question

This is a stripped down version of my program to illustrate the issue:

#include <functional>
#include <iostream>

template<class T>
class Piped {
public:
    typedef T value_type;
};

template<class P1, class P2, class T>
class PipeConnector : public Piped<T> {
public:
    PipeConnector(const P1 &p1, const P2 &p2)
     : m_1(p1), m_2(p2) { }

    bool run(const T &element) const {
        return m_1.run(element) || m_2.run(element);
    }
private:
    const P1 &m_1;
    const P2 &m_2;
};

template<class T>
class NullOp : public Piped<T> {
public:
    bool run(const T&) const {
        return false;
    }
};

template<class T, class Functor>
class FunctionOp : public Piped<T> {
public:
    FunctionOp(Functor f1)
     : m_1(f1) { }

    bool run(const T &element) const {
        return m_1(element);
    }
private:
    std::function<bool(T)> m_1;
};

template<class P1, class Functor>
auto operator|(const P1 &p1, const Functor &f2) {
    return PipeConnector<P1,
            FunctionOp<typename P1::value_type, std::function<bool(typename P1::value_type)>>, typename P1::value_type>(
                    p1, FunctionOp<typename P1::value_type, std::function<bool(typename P1::value_type)>>(f2));
}

int main() {
    auto p = NullOp<int>() | [](int x) -> bool { if (x < 10) { return true;} return false; };
    std::cout << p.run(20) << std::endl;
    return 0;
}

Compiling this program using g++ / clang++ -std=c++14 leads to a segfault. Adding -O3 to it, makes it run without a segfault.

When changing the PipeConnector to not store const references but storing copies, this works. I assume the problem is some lambda scope issue, but I don't understand what goes wrong. -O3 seems to elide the problem? Could you explain the issue to me, please?

Answer 1

The problem is that NullOp<int>() is a temporary to which you store a const-reference to inside PipedConnector. This temporary has full-expression lifetime so it does not exist after p has been initialized. When you call p.run(20) you then reference that temporary again, which has since been deleted. The UB that results from that can cause a crash.

Answer 2

Your operator|() creates a PipeConnector object, both of whose arguments are temporaries. The PipeConnector constructor then returns an object containing references to these temporaries. When that object's run method is invoked, the lifetime of the temporaries has expired.

The NullOp object has no state, and it probably doesn't matter (in practice) that its reference is dangling, but the same cannot be said of the std::function object constructed from the lambda. This is not the same as the lambda itself; the lambda itself is stateless, but the std::function operator contains a function pointer.

I suppose that with -O3 the compiler can figure out what function should be invoked when the std::function member variable is called, and so it inlines the call. But it is still UB, even when it appears to work.

Edit: OP suggests that the lifetime of the temporary should be extended because it is bound to a reference. However, in this context, that does not apply. See Does a const reference prolong the life of a temporary?

There are three references initialized with temporary objects in the constructor of the PipeConnector created in the call to operator|(). The first of these, NullOp<int>(), is the argument to the operator|() function, and its lifetime is explicitly not extended by the wording of §12.2 [class.temporary] paragraph 5.1:

A temporary object bound to a reference parameter in a function call (5.2.2) persists until the completion of the full-expression containing the call.

The other two temporary objects are an instance of std::function<bool(int)> which results from the conversion of a lambda, used in the initializer of a FunctionOp<int, std::function<bool(int)>>, and the constructed FunctionOp itself. In versions of the draft standard available in 2013 and the first half of 2014, this case (which is very similar to the function call case) had similar wording:

A temporary bound to a reference member in a constructor's ctor-initializer (12.6.2 [class.base.init]) persists until the constructor exits.

However, that sentence was deleted in the proposed resolution to DR 1696 (committed to the draft standard 29 September 2014). I believe the sentence was deleted for clarity; as far as I can see, the situation referred is marked as invalid by the other modifications in the resolution to DR1696, especially the new paragraph 8 in §12.6.2:

A temporary expression bound to a reference member in a mem-initializer is ill-formed.