Bug 162695 - StringView should not delete the StringImpl it is viewing.
Summary: StringView should not delete the StringImpl it is viewing.
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Template Framework (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mark Lam
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-28 11:27 PDT by Mark Lam
Modified: 2016-09-28 11:54 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Lam 2016-09-28 11:27:37 PDT
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.
Comment 1 Mark Lam 2016-09-28 11:32:56 PDT
To clarify, this issue only manifests when CHECK_STRINGVIEW_LIFETIME is enabled.
Comment 2 Mark Lam 2016-09-28 11:36:54 PDT
Hmmm ... I'm wrong.  Deleting the UnderlyingString should not delete the underlying StringImpl.  I'll dig a little further.
Comment 3 Mark Lam 2016-09-28 11:54:42 PDT
I misread the code.  This is not the issue I'm seeing.