Bug 44989 - Make RefPtr complain if you use them after they are released
Summary: Make RefPtr complain if you use them after they are released
Status: ASSIGNED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Template Framework (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-31 14:37 PDT by Darin Adler
Modified: 2022-09-19 10:15 PDT (History)
4 users (show)

See Also:


Attachments
Patch (7.95 KB, patch)
2010-08-31 17:50 PDT, Anders Carlsson
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Adler 2010-08-31 14:37:39 PDT
Anders had a great idea: Once you pass the value of a PassRefPtr you should get an assertion if you try to use it. Idiomatically, we don’t use PassRefPtr after passing its value along. Its value is zero then, but in debug versions it could instead have a “known bad” value so we can catch incorrect uses.

RefPtr could use the same feature. As could PassOwnPtr and OwnPtr.
Comment 1 Anders Carlsson 2010-08-31 17:50:17 PDT
Created attachment 66153 [details]
Patch

Here's a patch that does this for PassRefPtr. One thing we should figure out if it's valid to assign into a pointer that has been released. (See the editing change)
Comment 2 Ahmad Saleem 2022-09-17 16:57:01 PDT
PassRefPtr is not used anymore but if this need to be extended for RefPtr then please decide accordingly. Else this can be marked as "RESOLVED WONTFIX". Thanks!
Comment 3 Alexey Proskuryakov 2022-09-18 17:18:52 PDT
We now have ASan poisoning that serves a similar purpose (only in ASan builds, but it's good to avoid slowing down debug builds).

Not in RefPtr though, but it's zeroed when moved out, so I'm not sure how this is applicable to RefPtr.
Comment 4 Darin Adler 2022-09-19 10:04:17 PDT
I think it depends if we want our code to treat RefPtr as "zeroed after moved out" or "invalid to read after moved out". When we want it actually zeroed we could use std::exchange(a, nullptr). But if we want to have the "can rely on it being zero" then we should leave it as is.