Currently, StringView uses a UnderlyingString that starts with a refCount of 1 independent of how many references to the underlying StringImpl exists. In the StringView destructor, it then decrements its UnderlyingString refCount, and if that refCount is now 0, it proceeds to delete the referenced StringImpl even if the StringImpl's refCount is non-zero. As a result, this prematurely frees the StringImpl that other code is still expecting to be alive.
To clarify, this issue only manifests when CHECK_STRINGVIEW_LIFETIME is enabled.
Hmmm ... I'm wrong. Deleting the UnderlyingString should not delete the underlying StringImpl. I'll dig a little further.
I misread the code. This is not the issue I'm seeing.