Liftetimes: shared_ptr questions

[jrmuizel]

I'm trying to better understand how the lifetime analysis deals with shared_ptrs. I was not able to figure out why the following program would not compile with lifetime analysis turned on.

using namespace std;
struct B;

struct A
{
        shared_ptr<B> b;
        int k;
};

struct B
{
        unique_ptr<A> a;
};

void foo(A* a)
{
        a->b->a = nullptr;
        a->k = 5;
}

void d(A* a, shared_ptr<B> b)
{
        a->b = b;
}
void g(B* b, unique_ptr<A> a)
{
        b->a = move(a);
}

int main()
{
        shared_ptr<B> b = make_shared<B>();
        auto a = make_unique<A>();

        a->b = b;
        d(a.get(), b);
        g(b.get(), move(a));
        foo(b->a.get());
}

[hsutter]

I haven't looked at your code, but note that the Lifetime spec currently has a placeholder for shared ownership (e.g., shared_ptr) and owner-of-nonowner (e.g., vector<T*>) which are still to be written up. Once it's in the spec, then sometime later the checker will implement it.

[theres-waldo]

Is the "Lifetime spec" https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetimes%20I%20and%20II%20-%20v0.9.1.pdf, or something else?

[hsutter]

That's it (not yet 1.0 because of fleshing out shared and owner-of-nonowner), and the section III is forthcoming with detailed rules tables of interest primarily to compiler writers and academics.

BTW, when you wrote

the following program would not compile with lifetime analysis turned on

I assumed you meant you were using a checker implementation, but then remember we were just about to ship what I thought was the first one. So which tool are you using where you are turning lifetime analysis on?

[jrmuizel]

I was just checking it through in my head. There's an intentional use-after-free here "a->k = 5;" that the lifetime checker would need to catch.

[jrmuizel]

Any idea when we can expect the more fleshed out spec? Also, if you don't mind, could you take a look at this program and give some hints as to where it should fail?

[hsutter]

Sooner rather than later, but no firm ETA. Right now most of us who are taking the lead in the Guidelines are consumed with at a spike of standards work that happens once every three years and will end around June, with a big flurry of activity right now: The deadline for finalizing the feature set of the C++17 standard is coming at the June meeting, and many of the decisions must be made at the one meeting we have before that which starts at the end of this month. So, we'll be slower to get to some other things until the C++17 feature set has been wrapped up and C++17 sent out for its major international comment ballot. The good news is that standardization overlaps a lot with the Guidelines -- for example, one of the things we (mainly Neil) are heads-down with is writing up the GSL span<>/string_span<> spec for an ISO submission, which will also fill in the spec here in the Guidelines. So do expect continued progress, but just not on everything at once... stay tuned, and thanks for your interest!

[mystor]

I'm interested in how the analysis handles loops like this too. I've simplified the example a tiny bit and added comments to explain how it represents a use-after-free. I'm curious as to whether or not this would be caught by the analysis, because the only ways I can think of catching it would be very disruptive to existing C++ code bases.

#include <utility>
#include <memory>
using namespace std;

struct A
{
  shared_ptr<B> b;
  int k;
};

struct B
{
  unique_ptr<A> a;
};

void use_a(A* a) {
  // Destroy the unique_ptr which is keeping a alive through a cycle
  a->b->a = nullptr;

  // Use-after-free on the now-invalid a pointer
  a->k = 5;
}

void move_a_into_b(B* b, unique_ptr<A> a)
{
  b->a = move(a);
}

int main()
{
  shared_ptr<B> b = make_shared<B>();
  unique_ptr<A> a = make_unique<A>();

  // Store a reference to b in a, such that b may be accessed through a
  a->b = b;
  // Move the a object into b, creating a cycle
  move_a_into_b(b, move(a));
  // Use a, troggering a use-after-free
  use_a(b->a.get());
}

[AndrewPardoe]

Per our editors' discussion, we're actively working on revising the Lifetime spec. This example will be useful in that effort so we'll assign it to Herb and Neil.

[rishitc]

Hi,
Is there any update on how the analysis tools would detect/catch the issues in the above mentioned examples?
Any updates would be helpful.

Thanks.