The pmr crash is the buffer that died first

The first std::pmr crash most people hit rarely comes from a memory resource they wrote. It is an ordering bug: the buffer the container allocates from goes out of scope while the container is still alive, or is destroyed one line too early.

A pmr container holds a pointer to its resource and calls back into it to free memory when the container is destroyed. So the resource has to outlive the container. In a single scope that reduces to a rule about declaration order, because destructors run in reverse:

The resource is declared first and the vector second, so at the closing brace the vector is destroyed first. It deallocates into a resource that is still alive, then the resource itself is destroyed. The output shows that order directly. Swap the two declarations and the vector would deallocate into an object whose lifetime has already ended, which is undefined behavior and usually a crash or a corrupted heap.

Where this bites in real code

The scope version is easy once you have seen it. The dangerous version is when the resource and the container live in different places: a monotonic_buffer_resource as a local, handed to a container stored in a member of a longer-lived structure, or a stack buffer passed to a resource that outlives the frame. The compiler will not stop you. There is no borrow checker here, only the rule that the resource must still be alive at every allocation and every deallocation the container performs, including the deallocations in its destructor.

The habit that avoids it: give the resource a lifetime at least as long as everything that allocates from it, and prefer to declare or own the resource at the same level as the container, resource first. The bug is boring once you know it, and expensive when you do not.

Sources: PVS-Studio, “How frivolous use of polymorphic allocators can imbitter your life” · Arthur O’Dwyer, “A not-so-quick introduction to the C++ allocator model”.